The inability of the GIMP developers to work with others to incorporate needed features was the primary reason.
Look at the difference between how different open-source projects operate. Some foster collaboration and encourage outside contributions, e.g. Linux. Others are completely insular and barely tolerate it. The GIMP maintainers fall into the latter category. Unless you're part of the inner clique, you won't get anything merged.
It's kind of sad that the Cinepaint people got several paid staff to lift the GIMP functionality to the point it had very high-profile commercial use with some really useful features, and yet the GIMP developers were too stubborn to acknowledge this effort and work with them to get the functionality into the GIMP core.
Sadly, this is not unique to the GIMP. I, and other commercial developers, had exactly the same experience with GTK+ and GNOME libraries. The developers wanted to hack on their pet thing, ignore outside contributions, and this is simply not compatible with commercial timelines and realities. But it can be, and it can work very well, for projects which are willing to engage with outside work. It can work out to be very mutually beneficial with some give and take on both sides. I was on the GIMP mailing lists at the time and followed this saga for years. It's a crying shame it was deliberately ignored.
My first patch to an open-source project ever was to GIMP, as a 16-year-old with zero OSS experience. I actually didn't have much problems getting it merged, so I don't think it was as insular as you make it out. :-) But it wasn't a huge rearchitecting, like 16-bit support is.
Part of the problem as I saw it is that GIMP felt into a second-system effect, where they would do things “right” using GEGL instead of taking back the Film GIMP patches, and GEGL took literally 15 years before it worked reasonably well.
Hi Steinar (long time, no see)! You are right that there are very big differences in scope with large features vs small bugfixes.
I was one of the GIMP "Print" plugin maintainers for several years. It ended up being split off as a separate project, turned into a shared library, renamed to Gutenprint, and became the highest quality set of printer drivers on Linux, particularly for photographic printing, due to the use of speciality dithering algorithms (Raph Levien's EvenTone), custom dithering matrices and hand-tuned support for mixing light and dark inks with variable drop sizes, CUPS support, and eventually became the default MacOS X printer drivers in the early years of MacOS X. It went from a tiny plugin as part of a niche application, to being the default means of printing on all Linux and MacOS X systems. I would argue it is many times more successful than the GIMP application, despite being less recognisable to end users, it is nevertheless there under the hood quietly turning rasterised page input into individual ink droplets on pages (or toner on lasers). It far surpassed the quality of most/all commercial RIPs and vendor drivers at the time, and maybe still does.
This occurred because the lead developer of this sub-project was willing to delegate responsibilities and collaborate with others. For example, as a young-but-keen amateur, I single-handedly converted it to build as a shared library, moved the build to use Autoconf/Automake/Libtool (this was 2001, today I'd have used CMake), and this enabled it to be used directly within the GIMP as the Print plugin, or as a CUPS driver, or as an IJS (InkJet Server) driver. That willingness to consider and accept contributions from others made this project an outstanding success. I wasn't the only one either, the project benefitted from the expert contributions from many people with a diverse range of interests and skills, with a good project manager to oversee it all (Robert Krawitz).
In my humble opinion, that is what separates the projects. In order to grow both the developer base and the user base, you need effective project management. And managers need to be able to step back and delegate.
The GIMP developers have never really been able to do this. They have to write every line themselves. This is why its development has basically been stagnant for over 15 years, because they had to do GEGL themselves, even though there's only one part timer on it. Having it all written in C doesn't help. Graphics does lend itself to higher level abstractions which they can't use. I'd consider GEGL a wasted effort myself; it was obsoleted by GPU compute before it was even part way complete.
Yes, I remember all the traffic about gimp-print on the mailing lists :-) It was never really the core of my interests, and eventually, I moved to other things. Probably everything you say is right, but also, image processing is sort of a niche topic, so it's hard to attract people in the first place.
That inability doesn't only show in not implementing features but also in the way functions are implemented - A good example is the forced save to xcf introduced in 2.8. Apparently it is more professional. Anyway there is a patch for that by vitalif. You can find prebuild packages here: http://vmx.yourcmc.ru/var/debian/unstable/
It will fix most problems by removing the save/export filetype restriction and disabling some forced warnings.
Another thing I found recently when trying to use GIMP for a simple task was that GIMP is "not a drawing program". You have no good way to handle simple vector shapes and lines. There are some semi-functional workarounds using selections or the drawing tool or even a filter (render/gfig). These all have various downsides in that they cannot be easily adjusted once applied to an image.
There is no good reason for simple shape vector editing not being in GIMP since you need some vector functions for say Font rendering. Similar Apps I cannot use in Linux (wine is not an option thanks to DRM) have had functions like that since the early 90ies.
The whole ecosystem around gtk is extremely insular, the devs are hostile and think the users idiots for not doing things the right way.
Compare to the qt krita and you see the difference. It's a paint program, but it already works better for most photo manipulation tasks. Give it another few years of development and gimp will only be used in scripting pipelines.
I think most of the gtk maintainers are European, hence the hostility.
I haven't had a lot of luck communicating with any Open Source projects in the EU over the years. I will probably end up forking any projects that are important to me.
As I've mentioned before, HN should ban European IP addresses.
About save/export debacle, someone made a plugin which makes saving to non-xcf easier [0] - big thank you to them. It allowed me to still use Gimp when I had to manually edit 100s of PNGs.
It is incredibly frustrating to see good software (I love Gimp otherwise) tarnished with such rookie mistakes/decisions.
Because I'm not exporting but saving, and it doesn't work the same way as Ctrl+S should. If I have opened a file and changed it, I expect Ctrl+S(/E) to override it. What I do not want it to select a file or answer dialogs, asking me if I really want that. And when I close the app I don't want to confirm that I really don't care about xcf and yes, I want my changes "lost". And I especially don't want to lose my changes because I thought that I have pressed (Shift?)+Ctrl+E and that this warning can be disregarded.
I might be wrong in some details because it's been a long time since I last used Gimp without this plugin, but the whole process is so brain-dead that it is incomprehensible how anyone could defend it. I am guessing that if one of the core developers had to manually edit 100 PNGs they would revert their position in a blink of an eye. /rant
GIMP is approaching great in so many areas - its like finding a turd was added on purpose to a great meal - you would get more upset about that than if you learned the same about a pile of dirt.
Absolutely. For my workflow, the XCF requirement and the need to manually export were completely wrong. In the 23 years I've used it, I've never once needed the XCF file format. I acknowledge that others will need it, but I don't, and the change to the workflow made it significantly less usable for me.
This again comes back to the project management and project goals. There is very clearly a desired workflow and feature set that users are expected to use, and deviations from this workflow are not desired or well supported, and accommodations for non-standard workflows are not well received.
As a minor developer of open-source software, I've always been surprised at the diverse range of uses people have attempted with my software. Often things I'd never considered. In most cases, I tried to accommodate these uses so long as they could fit within the application design, and occasionally with some refactoring to fit them in. Because in most cases this was of net benefit to the application, widening its appeal and usability, and driving cleanup of the architecture to make it more flexible and more amenable to extension.
The unwillingness of the GIMP developers to support fairly basic vector and path operations speaks volumes. There's clearly a demand for it. They would be self-contained and not have any major impact upon the wider application. And yet, they have been repeatedly rejected. If I was the maintainer, I'd have considered and allowed their addition. But it seems that the GIMP developers do not want to expand the remit of their application, even if it would be of net benefit.
Please don't blame open source volunteers for not having the right skillset or for not having enough time to address every concern or merge every patch that comes their way. Everyone's got their strengths and weaknesses. I'm sure the GIMP developers would love to make a program that is really good at everything, but reality has a way of making that difficult. If you've got some spare time and can help with reviewing and merging and maintaining patches, maybe you can talk to them and work something out? Remember that any patch that gets merged has to be maintained for several years, so maybe you can see their reluctance there.
I'm well aware of the constraints of open source development and project management, having been involved in it for nearly 25 years at this point. In the case of this project, I was involved with it for several years as a maintainer of the Print plugin, if you care to read some of my other posts about the history.
You're wrong about the GIMP developers wanting a program that is "really good at everything". If that was the case, then they wouldn't have deliberately rejected so many proposals for improving workflows and adding features over the years. Film-GIMP is the most high-profile example, but there are dozens more. This is nothing to do with not having enough time. It's a deliberate design choice, which is theirs to make. They chose not to foster a community of contributors around the project. And they chose not to implement many of the most basic features their user base asked for. Again, their choice.
As for "talking to them and working something out", that hasn't happened in the entire history of the project. What is missing here isn't a lack of time or a lack of technical skill. It's a lack of effective project management, a lack of direction, and an inability to delegate.
I think your characterization isn't exactly correct, they've declined to implement some features, but they've also implemented a lot of other ones.
>What is missing here isn't a lack of time or a lack of technical skill. It's a lack of effective project management, a lack of direction, and an inability to delegate.
Please don't do this, this is splitting hairs. Some people don't have the project management skills to do that. I've read your other posts, if you have the project management skills, then you'd be a great candidate to step in and do that. If you don't, then this still isn't helping the problem. The productive thing to do would be to find a capable project manager.
I'm not sure I see the problem: 'Export', and 'Export as' works as 'Save' and 'Save as'. This i like 'Export to PDF' in a word processor. If you never save in GIMP, I suppose you don't use layers?
The problem is that for those of us that used it since the beginning (1997 in my case), it's a change which broke the workflow which worked for 15 years for zero benefit for any user, old or new. I still get it wrong every time a decade on. The keyboard shortcuts are awkward, and it's all around a bad choice for usability. It has no actual benefit. Its only purpose is for the developers to force you to use XCF in a not-very-subtle manner.
I do use layers sometimes. But all of my input and output images are PNG, TIFF or JPEG and I have no use for the intermediate state. XCF is a non-standard application-specific format which has no use other than with the GIMP. It has its place, but the assumption that it is the central part of the workflow of end users is simply incorrect. It wouldn't have caused so many complaints if it was the case.
> Some foster collaboration and encourage outside contributions, e.g. Linux. Others are completely insular and barely tolerate it. The GIMP maintainers fall into the latter category. Unless you're part of the inner clique, you won't get anything merged.
I can't speak to this, as I don't contribute to them. However, for all the criticisms of Gimp and its development team, for photoediting no open source SW comes close to the power of Gimp.
> The inability of the GIMP developers to work with others to incorporate needed features was the primary reason.
I don't know. I felt like Adobe and other companies saw the market and wanted to win it. It's easier to grab marketshare when you can hire lots of developers to implement all the features your customers are asking.
When Cinepaint announced that were moving off GTK+ and onto FLTK probably just accelerated the end of Cinepaint.
I haven't seen an FLTK app in years. Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern?
FLTK still widely used in various scientific apps.
> Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern?
Probably the same. For example, here is screenshot[0] of the OpenVSP[1] - an actively maintained parametric 3D CAD app by NASA.[2]
But also there is `fl_imgtk` — a small library for FLTK image toolkit, designed to use some useful effects in FLTK GUI (better image, better speed, better quality).[3]
Yet another thing is `fltk-rs`[4] - Rust binding to FLTK, with custom theming module.[5]
It has improved a bit from what I can see, but I wouldn't say it's "modern".
Interesting. It still appears to have the issue with text flow I ran into years ago where text would overlap with the button outline, rather than increasing the button outline to accommodate the text.
That was the one thing I didn't like about it. It made the GUI's look kinda unprofessional.
> It still appears to have the issue with text flow I ran into years ago where text would overlap with the button outline, rather than increasing the button outline to accommodate the text.
OpenVSP probably uses 'vanilla' FLTK, but there is no such issue on screenshots of Rangi's Tilemap Studio[0,1], where custom FLTK widget themes used.
> That was the one thing I didn't like about it. It made the GUI's look kinda unprofessional.
JFTR, Take a look on AzPainter[2] and its toolkit on top of X11.[3,4]
I don't think it's worth comparing it with Adobe, since the developers have never really competed with it. It's its own thing, and the decisions and development roadmap stand on their own.
Cinepaint got stuck as the fork diverged increasingly from the mainline code. They ended up on with a branch of GIMP 1.0.x using GTK+ 1.x, and the porting effort to bring it up-to-date with the GIMP mainline and GTK+ 2.x was insurmountable. I wasn't aware of the switch to FLTK, but last I looked FLTK was indeed primitive and dated. But very functional.
The Cinepaint developers had very specific commercial priorities, somewhat at odds with the GIMP developers, and if porting to FLTK got them a working product to satisfy their needs, I can certainly see that being a reasonable choice. If anything, it really makes a point toward the maintainability of C GTK+ applications (many of us have been there; I ported over to C++/Qt myself).
We used it at DreamWorks Animation, but also had our own various 2D bitmap editing tools.
I can think of a few reasons it fell out of favor in the 3D animated film space. Any process that required artists to come in after a render was complete is bad news for your budget. The more you can accomplish inside of your surfacing and lighting tools, the better.
For surface creation, artists in general would prefer to use tools that they are familiar with, and if your pipeline can support export from Photoshop, then that is they are going to want to use.
While there are still a lot of proprietary tools in use for lighting and rigging, the days of completely proprietary tool chains and pipelines are over. Software suites of no longer running on SGI boxes with a lot of proprietary formats. A lot of work has been done on interchange formats so it is easier to get your data in and out Maya, Photoshop, etc.
> While there are still a lot of proprietary tools
I think you mean something like “bespoke” or maybe just “cinema industry specific”; all your counterexamples to “proprietary tools” are, in fact, proprietary tools.
Proprietary software but "open systems", in the way that OpenVMS is certainly not open source, same with OpenStep, and several other examples I'm forgetting. But they're documented and accept/output open formats, as opposed to being giant proprietary monoliths.
(this is why some people are very insistent on always using the full "FOSS")
Ah yes. Good point. We wrote a lot of custom software, internal to DreamWorks (or PDI in my case) with no intention of commercializing them. Some of the tools did end up getting used by other studios, but that wasn't an intended goal.
Well, in the first place the Cinepaint maintainer, Robin Rowe, wasn't a developer. He kind of inherited the tarball with the 16 bit patches, then tried to drum up financial support, without being able to actually maintain the codebase. There was one other developer interested in the codebase, but since Robin never really made releases, their work never really got out. And... Sorry, but "if bitdepth == 8 then, else if bitdepth == 16 all through the codebase just wouldn't have been maintainable for anybody.
Then a Scottish university donated a tarball of a research project to the Cinepaint project so then Robin had to maintain two completely different codebases, one which was presented as the successor of the first one.
Then Robin decided that the real problem was the antiquated autohell build system, so he decided that having waf, scons and cmake build systems was going to draw in developers. (The blogs announcing that aren't on cinepaint.org anymore, maybe the wayback machine still has them?)
That didn't work either, of course, and nothing much happened after that. Cinepaint.org became more and more vandalized, nobody put money in the project, and, well, seeing I'm the Krita maintainer, I probably should stop reminiscing, and go back to coding :-)
My favourite memory of Cinepaint was being at a SIGGRAPH exhibition booth (Silicon Grail's I presume) and seeing how they were using GIMP/Cinepaint for wire removal in the X-Files movie. I asked Yosh how the layers dialog looked and he popped it up. It started loading all of the full-def movie frames to make thumbnails, then the machine ran out of memory and IRIX crashed!
> In 15 years, we'd get 10 doublings, which would make modern computers 1000x faster. Our original Toy Story frames were averaging four hours, which is 240 minutes, so we might naively expect that we could render frames in just 15 seconds. We didn't really achieve that: our average render times were probably on the order of 2-4 minutes per frame (the original productions weren't instrumented to keep accurate statistics on rendertime, and we never bothered to really reinstrument them to do so.) The renders were fast enough that most of Toy Story was rerendered in "render farm white space", we never had any sizeable backlog of work queued on the farm.
What's confusing? They can re-render the scenes from the original source. At some point in the transition from VHS to DVD to Blu-Ray, they may have even done a "remastered" re-release (hiring staff to touch up textures and so on), and if so, they could make use of that work, too.
Rerendeirng old cinema cg is anything but trivial. Production pipelines are incredibly complex and are a fast moving target. Getting something going again is a very complex and tedious task of software archeology against projects that often only had a single company using them. Many dependencies will be unavailable or incompatible with current systems.
When old content that doesn't have a high resolution film or digital master copy is remastered to HD, it's done using super resolution tools that do their best to infer extra detail based on the existing data.
Also, often special effects are done as manual one-offs on top of what comes out of the renderer (with whatever software package and techniques that happened to fit the bill for that particular effect); it's not like you can just type “make” and out comes the movie. It's certainly _easier_ to do a higher-res version of an animated movie than a live-action one, but it's still a lot of work.
As with software development, some people have done this before and learned their lesson, others never do.
Once upon a time it was completely normal to have manual processes in your final build process. Something like a word processor in the 1990s would have one of the team sat at a machine building the "gold" binaries by hand, maybe following a checklist, likely hand written. OK, so we need to drag all the files except these two into this folder, then run this program...
Today, hopefully most of you today would see that's awful and you'd forbid it on a project you led and insist on CI instead.
Toy Story in particular had to be re-rendered to produce the 3D re-release over a decade later, and Pixar did that. They chose not to later re-render to 4K because in their opinion it isn't worth the effort compared to just upscaling it.
As another comment pointed out: Toy Story was re-rendered at great effort for 3D. That's the exception not the norm. They didn't feel it was worth it to do it yet again for the 4K version which is simply upscaled.
It is in no way a "download the archive and type make again" sort of situation. It's a huge effort.
Are your comments actually informed or are they just synthesis (guessing)?
> “We had to have some very, very smart people at Pixar go back in and write some software and figure out a way to make it so that those files would render on our current computers,” he said.
>It took four months to resurrect the old data and get it in working order. Then, adding 3-D to each of the films took six months per film.
I am a filmmaker and VFX artist and boy are you wrong.
Doing a 4k scan of a film that only ever was scanned for a DVD release is trivial, provided you still have the masters.
Doing the same thing with a film which was made 1995 as a digital animation is anything but trivial. This is not your "I just have to select a higher resolution and render everything"-thing.
- certain visual results might be bound to software versions that are so old grabbing a copy of them and making them run would be a challenge in itself
- there might be manual processes which need to be redone in order to get the final result — IF they have been documented
- there might be file formats in use which are no longer readable, or might be read differently
Scaning a film and retouching it is trivial, redoing a digital animation that was top notch in 1995 is not.
A good example of this was the recreation of Star Trek: The Next Generation in Blu-Ray resolution. The main scenes were still available on film and could be rescanned. But all the special effects (phaser beams, transporter sparkles, etc) had been rendered using late 80's technology. And had to be recreated from scratch.
Some of the model shots also had to be entirely redone via 3D effects, such as the Crystalline Entity in S05E04. Paramount spent millions on this project, which were never recouped as the discs were released just as streaming took off.
Technically you upscale whenever you full-screen the video player on your computer (unless the video is already at your monitor's native resolution), but upscaling algorithms that don't have to be fast enough to run in real time can do very impressive things to the video if the encoder knows what they're doing (and it can do really bad things if they don't).
Also, "4K" is generally a shorthand for the UHD format, which also brings in HDR. Lots of movies that weren't shot in 4K or were shot on a film stock that you just can't extract 4K worth of information out of can still massively benefit from the wide gamut offered by HDR. 24-bit color isn't enough to accurately represent a lot of content. Of course this means you have to have a monitor that can do HDR, and not just that, do it properly. A lot of cheaper 4K monitors claim to support HDR, but the display can only output SDR: in this case "supporting" HDR just means the firmware can understand HDR signals and tonemap HDR to SDR so you don't have to have your player software do the tonemapping.
No. Cinepaint was merely a raster paint program with 16-bit colorspace which made it suitable for feature work. It didn't have programmable animation capability but did have onion skinning so that cel-style animation could be done, albeit painfully.
Edit: Oh, and that, very importantly, ran on SGI/IRIX.
So that pretty much caused whoever still used it to stop. They sold to a new company who stopped that practice but I can’t think of many projects that want a managed SCM that felt there was any reason to switch to sourceforge from GitHub or gitlab after that, which is where most projects have ended up one way or another.
Their new owners now call sourceforge a place for “business software” which seems like hopefully the final stage which will bring sourceforge’s long slow decline to its end.
Edit: it looks like their latest owner (2020) is slashdot. So. I guess they will capably oversee its continued slide to irrelevance.
Yeah, the moment they started bundling crapware, the fall was extremely fast. It's a hosting site that's fairly-strongly correlated with technically-adept users: burn them like this and they are never coming back, and they'll loudly tell everyone they know to do likewise.
> it looks like their latest owner (2020) is slashdot
Not really, it's actually that Slashdot had also been sold to the same company! Just like SourceForge, under Dice.com's new management, it caused significant negative reactions among users in 2014 (that even made it to the Washington Post [0]), , and led to the creation of a Slashdot fork - Soylent News [1]. Later Dice.com sold both company to someone else again.
It is interesting to think that GIMP once had such a lead but today is playing catch-up. Blender and Krita area canonical examples success stories in the are now.
Strong disagree. For image manipulation, Krita is not even close to Gimp's capabilities. I dislike that GIMP keeps being compared to Krita, when the goals of the two projects are quite different. Krita is more for digital artwork, whereas GIMP is more for photo manipulation.
Ditto with Blender - it's like comparing Blender with Photoshop - it makes no sense.
I used to do heavy photo editing in GIMP. I know of no one who does serious photo editing in Krita.
I used Cinepaint all the time back around 2005-2007. You could work with 3D renders at higher bit depths, which meant a lot when you were working with a limited-scope FOSS 3D package on a Linux system in the first place. Much post was done. Thanks to those who worked on the project!
I remember that story and found it really unfortunate. On the one hand you had apparently professionals that were very interested in using a fork of GIMP that provided a specific feature they needed.
The GIMP devs said something along the lines of "we plan to implement this in a different way, at some point, we can't tell when this is gonna happen" - and eventually Filmgimp/Cinepaint became a full fork and the chance of getting the support of those movie studios to improve GIMP itself vanished.
Wonder what could have been if GIMP would've been smarter on this.
Unfortunately the primary maintainers of GIMP basically have an attitude of "we want to do it our way, and at our pace", and are not willing to accept any patches outside of that pattern.
Which is both a blessing and a curse - on the one hand, consistency, on the other hand, not welcoming to people who want to try something different.
Main problem for gimp now is under-funding. Although slow, their approach may be sound: features will land once they are good enough to work and well written enough to be maintainable. This may be slow but keeps the mechanism working for decades even with a very small team.
Studios need features implemented immediately. That usually generates functional but unmaintainable solutions. Note that filmgimp/cinepaint was abandoned by studios as well as gimp developers.
What studios should have done: fund main gimp developers and hire other developers to help accelerate the development of GEGL or other multi bpp lib. What gimp developers should have done: try to merge enough of the studios changes to keep them interested.
We can look back in hindsight and say that, but at the time it may have just been that nobody had the resources to do those things.
I agree with your sentiment that some forking is preventable, but other times it isn't. Changing the fundamental design of the program tends to be one of those things that can't really be merged without causing a lot of other problems.
I don't understand this comment, every single software project in existence is like that. The pacing and threshold of what they'll accept is just different between projects. If you had some patches that get rejected, that's unfortunate. But that's a risk you take with any project, and you're also asking the developers to take a risk by accepting your patch. Some may have higher risk tolerance than others.
Yes that's true. But by accepting an unusual patch you could also risk having a feature that doesn't fit in well with the rest of the project, breaks something unexpected in another area of the project, takes up a lot of maintainer time that could be spent on other things, could break further in the future and need to be removed, which would further upset the users... So it's a trade-off that every project must decide to make in their own way. AFAIK it's not possible for a project to bend to every potential contributor's will, else the project drifts into the old unmaintainable big ball of mud.
If you knew a way to develop software like that where everyone could get their way all the time, please let me know, we could turn that into a product and get really rich selling it to every software company.
> an attitude of "we want to do it our way, and at our pace"
In Japanese, there is a term for this, and it's actually borrowed from the English "my pace" (マイペース). If somebody has this attitude, you can call them a my-pace. From what I've seen, that term is always an insult: nobody ever calls someone else a my-pace as a compliment.
86 comments
[ 4.8 ms ] story [ 165 ms ] threadLook at the difference between how different open-source projects operate. Some foster collaboration and encourage outside contributions, e.g. Linux. Others are completely insular and barely tolerate it. The GIMP maintainers fall into the latter category. Unless you're part of the inner clique, you won't get anything merged.
It's kind of sad that the Cinepaint people got several paid staff to lift the GIMP functionality to the point it had very high-profile commercial use with some really useful features, and yet the GIMP developers were too stubborn to acknowledge this effort and work with them to get the functionality into the GIMP core.
Sadly, this is not unique to the GIMP. I, and other commercial developers, had exactly the same experience with GTK+ and GNOME libraries. The developers wanted to hack on their pet thing, ignore outside contributions, and this is simply not compatible with commercial timelines and realities. But it can be, and it can work very well, for projects which are willing to engage with outside work. It can work out to be very mutually beneficial with some give and take on both sides. I was on the GIMP mailing lists at the time and followed this saga for years. It's a crying shame it was deliberately ignored.
Part of the problem as I saw it is that GIMP felt into a second-system effect, where they would do things “right” using GEGL instead of taking back the Film GIMP patches, and GEGL took literally 15 years before it worked reasonably well.
I was one of the GIMP "Print" plugin maintainers for several years. It ended up being split off as a separate project, turned into a shared library, renamed to Gutenprint, and became the highest quality set of printer drivers on Linux, particularly for photographic printing, due to the use of speciality dithering algorithms (Raph Levien's EvenTone), custom dithering matrices and hand-tuned support for mixing light and dark inks with variable drop sizes, CUPS support, and eventually became the default MacOS X printer drivers in the early years of MacOS X. It went from a tiny plugin as part of a niche application, to being the default means of printing on all Linux and MacOS X systems. I would argue it is many times more successful than the GIMP application, despite being less recognisable to end users, it is nevertheless there under the hood quietly turning rasterised page input into individual ink droplets on pages (or toner on lasers). It far surpassed the quality of most/all commercial RIPs and vendor drivers at the time, and maybe still does.
This occurred because the lead developer of this sub-project was willing to delegate responsibilities and collaborate with others. For example, as a young-but-keen amateur, I single-handedly converted it to build as a shared library, moved the build to use Autoconf/Automake/Libtool (this was 2001, today I'd have used CMake), and this enabled it to be used directly within the GIMP as the Print plugin, or as a CUPS driver, or as an IJS (InkJet Server) driver. That willingness to consider and accept contributions from others made this project an outstanding success. I wasn't the only one either, the project benefitted from the expert contributions from many people with a diverse range of interests and skills, with a good project manager to oversee it all (Robert Krawitz).
In my humble opinion, that is what separates the projects. In order to grow both the developer base and the user base, you need effective project management. And managers need to be able to step back and delegate.
The GIMP developers have never really been able to do this. They have to write every line themselves. This is why its development has basically been stagnant for over 15 years, because they had to do GEGL themselves, even though there's only one part timer on it. Having it all written in C doesn't help. Graphics does lend itself to higher level abstractions which they can't use. I'd consider GEGL a wasted effort myself; it was obsoleted by GPU compute before it was even part way complete.
It will fix most problems by removing the save/export filetype restriction and disabling some forced warnings.
Another thing I found recently when trying to use GIMP for a simple task was that GIMP is "not a drawing program". You have no good way to handle simple vector shapes and lines. There are some semi-functional workarounds using selections or the drawing tool or even a filter (render/gfig). These all have various downsides in that they cannot be easily adjusted once applied to an image.
There is no good reason for simple shape vector editing not being in GIMP since you need some vector functions for say Font rendering. Similar Apps I cannot use in Linux (wine is not an option thanks to DRM) have had functions like that since the early 90ies.
Compare to the qt krita and you see the difference. It's a paint program, but it already works better for most photo manipulation tasks. Give it another few years of development and gimp will only be used in scripting pipelines.
I haven't had a lot of luck communicating with any Open Source projects in the EU over the years. I will probably end up forking any projects that are important to me.
As I've mentioned before, HN should ban European IP addresses.
About save/export debacle, someone made a plugin which makes saving to non-xcf easier [0] - big thank you to them. It allowed me to still use Gimp when I had to manually edit 100s of PNGs.
It is incredibly frustrating to see good software (I love Gimp otherwise) tarnished with such rookie mistakes/decisions.
[0] https://shallowsky.com/software/gimp-save/
I mean if you could just leave out the front side door you could use those resources to improve enter-abilty through the back hatch.
This could also improve the loading and unloading of goods through the back hatch for more professional uses.
I might be wrong in some details because it's been a long time since I last used Gimp without this plugin, but the whole process is so brain-dead that it is incomprehensible how anyone could defend it. I am guessing that if one of the core developers had to manually edit 100 PNGs they would revert their position in a blink of an eye. /rant
This again comes back to the project management and project goals. There is very clearly a desired workflow and feature set that users are expected to use, and deviations from this workflow are not desired or well supported, and accommodations for non-standard workflows are not well received.
As a minor developer of open-source software, I've always been surprised at the diverse range of uses people have attempted with my software. Often things I'd never considered. In most cases, I tried to accommodate these uses so long as they could fit within the application design, and occasionally with some refactoring to fit them in. Because in most cases this was of net benefit to the application, widening its appeal and usability, and driving cleanup of the architecture to make it more flexible and more amenable to extension.
The unwillingness of the GIMP developers to support fairly basic vector and path operations speaks volumes. There's clearly a demand for it. They would be self-contained and not have any major impact upon the wider application. And yet, they have been repeatedly rejected. If I was the maintainer, I'd have considered and allowed their addition. But it seems that the GIMP developers do not want to expand the remit of their application, even if it would be of net benefit.
You're wrong about the GIMP developers wanting a program that is "really good at everything". If that was the case, then they wouldn't have deliberately rejected so many proposals for improving workflows and adding features over the years. Film-GIMP is the most high-profile example, but there are dozens more. This is nothing to do with not having enough time. It's a deliberate design choice, which is theirs to make. They chose not to foster a community of contributors around the project. And they chose not to implement many of the most basic features their user base asked for. Again, their choice.
As for "talking to them and working something out", that hasn't happened in the entire history of the project. What is missing here isn't a lack of time or a lack of technical skill. It's a lack of effective project management, a lack of direction, and an inability to delegate.
>What is missing here isn't a lack of time or a lack of technical skill. It's a lack of effective project management, a lack of direction, and an inability to delegate.
Please don't do this, this is splitting hairs. Some people don't have the project management skills to do that. I've read your other posts, if you have the project management skills, then you'd be a great candidate to step in and do that. If you don't, then this still isn't helping the problem. The productive thing to do would be to find a capable project manager.
I do use layers sometimes. But all of my input and output images are PNG, TIFF or JPEG and I have no use for the intermediate state. XCF is a non-standard application-specific format which has no use other than with the GIMP. It has its place, but the assumption that it is the central part of the workflow of end users is simply incorrect. It wouldn't have caused so many complaints if it was the case.
I can't speak to this, as I don't contribute to them. However, for all the criticisms of Gimp and its development team, for photoediting no open source SW comes close to the power of Gimp.
I don't know. I felt like Adobe and other companies saw the market and wanted to win it. It's easier to grab marketshare when you can hire lots of developers to implement all the features your customers are asking.
When Cinepaint announced that were moving off GTK+ and onto FLTK probably just accelerated the end of Cinepaint.
I haven't seen an FLTK app in years. Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern?
FLTK still widely used in various scientific apps.
> Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern?
Probably the same. For example, here is screenshot[0] of the OpenVSP[1] - an actively maintained parametric 3D CAD app by NASA.[2]
But also there is `fl_imgtk` — a small library for FLTK image toolkit, designed to use some useful effects in FLTK GUI (better image, better speed, better quality).[3]
Yet another thing is `fltk-rs`[4] - Rust binding to FLTK, with custom theming module.[5]
[0] https://twitter.com/app4soft/status/1352349523549577219
[1] https://github.com/openvsp/openvsp
[2] http://openvsp.org
[3] https://github.com/rageworx/fl_imgtk
[4] https://github.com/fltk-rs
[5] https://github.com/fltk-rs/fltk-theme
Interesting. It still appears to have the issue with text flow I ran into years ago where text would overlap with the button outline, rather than increasing the button outline to accommodate the text.
That was the one thing I didn't like about it. It made the GUI's look kinda unprofessional.
OpenVSP probably uses 'vanilla' FLTK, but there is no such issue on screenshots of Rangi's Tilemap Studio[0,1], where custom FLTK widget themes used.
> That was the one thing I didn't like about it. It made the GUI's look kinda unprofessional.
JFTR, Take a look on AzPainter[2] and its toolkit on top of X11.[3,4]
[0] https://github.com/Rangi42/tilemap-studio
[1] https://hax.iimarckus.org/topic/7691/
[2] https://twitter.com/app4soft/status/1430517079346749440
[3] http://azsky2.html.xdomain.jp/soft/index.html
[4] http://azsky2.html.xdomain.jp/about_mlk_en.html
Cinepaint got stuck as the fork diverged increasingly from the mainline code. They ended up on with a branch of GIMP 1.0.x using GTK+ 1.x, and the porting effort to bring it up-to-date with the GIMP mainline and GTK+ 2.x was insurmountable. I wasn't aware of the switch to FLTK, but last I looked FLTK was indeed primitive and dated. But very functional.
The Cinepaint developers had very specific commercial priorities, somewhat at odds with the GIMP developers, and if porting to FLTK got them a working product to satisfy their needs, I can certainly see that being a reasonable choice. If anything, it really makes a point toward the maintainability of C GTK+ applications (many of us have been there; I ported over to C++/Qt myself).
I can think of a few reasons it fell out of favor in the 3D animated film space. Any process that required artists to come in after a render was complete is bad news for your budget. The more you can accomplish inside of your surfacing and lighting tools, the better.
For surface creation, artists in general would prefer to use tools that they are familiar with, and if your pipeline can support export from Photoshop, then that is they are going to want to use.
While there are still a lot of proprietary tools in use for lighting and rigging, the days of completely proprietary tool chains and pipelines are over. Software suites of no longer running on SGI boxes with a lot of proprietary formats. A lot of work has been done on interchange formats so it is easier to get your data in and out Maya, Photoshop, etc.
I think you mean something like “bespoke” or maybe just “cinema industry specific”; all your counterexamples to “proprietary tools” are, in fact, proprietary tools.
(this is why some people are very insistent on always using the full "FOSS")
Then a Scottish university donated a tarball of a research project to the Cinepaint project so then Robin had to maintain two completely different codebases, one which was presented as the successor of the first one.
Then Robin decided that the real problem was the antiquated autohell build system, so he decided that having waf, scons and cmake build systems was going to draw in developers. (The blogs announcing that aren't on cinepaint.org anymore, maybe the wayback machine still has them?)
That didn't work either, of course, and nothing much happened after that. Cinepaint.org became more and more vandalized, nobody put money in the project, and, well, seeing I'm the Krita maintainer, I probably should stop reminiscing, and go back to coding :-)
Toy Story was less than modern HD, yet you can pay extra to stream it in 4K from Apple! Not sure how that works!
https://www.quora.com/How-much-faster-would-it-be-to-render-...
Are you just guessing?
Whether it happened or not doesn't change that even if the original theatrical version was 1536×922, re-rendering for higher resolutions is trivial.
When old content that doesn't have a high resolution film or digital master copy is remastered to HD, it's done using super resolution tools that do their best to infer extra detail based on the existing data.
Once upon a time it was completely normal to have manual processes in your final build process. Something like a word processor in the 1990s would have one of the team sat at a machine building the "gold" binaries by hand, maybe following a checklist, likely hand written. OK, so we need to drag all the files except these two into this folder, then run this program...
Today, hopefully most of you today would see that's awful and you'd forbid it on a project you led and insist on CI instead.
Toy Story in particular had to be re-rendered to produce the 3D re-release over a decade later, and Pixar did that. They chose not to later re-render to 4K because in their opinion it isn't worth the effort compared to just upscaling it.
It is in no way a "download the archive and type make again" sort of situation. It's a huge effort.
It's not obvious whether any of the comments here that "they didn't feel it was worth it" are actually informed, or that's synthesis (guessing).
> “We had to have some very, very smart people at Pixar go back in and write some software and figure out a way to make it so that those files would render on our current computers,” he said.
>It took four months to resurrect the old data and get it in working order. Then, adding 3-D to each of the films took six months per film.
https://www.nytimes.com/2009/10/04/movies/04murp.html
Sounds like getting the render to work was about as much effort as converting to 3D.
Everything is trivial when someone else has to do it.
Everyone on HN who says something is "trivial" is someone who has never tried it.
Re-rendering source material for a different resolution is trivial.
Doing a 4k scan of a film that only ever was scanned for a DVD release is trivial, provided you still have the masters.
Doing the same thing with a film which was made 1995 as a digital animation is anything but trivial. This is not your "I just have to select a higher resolution and render everything"-thing.
- certain visual results might be bound to software versions that are so old grabbing a copy of them and making them run would be a challenge in itself
- there might be manual processes which need to be redone in order to get the final result — IF they have been documented
- there might be file formats in use which are no longer readable, or might be read differently
Scaning a film and retouching it is trivial, redoing a digital animation that was top notch in 1995 is not.
Some of the model shots also had to be entirely redone via 3D effects, such as the Crystalline Entity in S05E04. Paramount spent millions on this project, which were never recouped as the discs were released just as streaming took off.
(As a TNG fan, it was totally worth it.)
https://www.youtube.com/watch?v=2k7R_nYueBg
Technically you upscale whenever you full-screen the video player on your computer (unless the video is already at your monitor's native resolution), but upscaling algorithms that don't have to be fast enough to run in real time can do very impressive things to the video if the encoder knows what they're doing (and it can do really bad things if they don't).
Also, "4K" is generally a shorthand for the UHD format, which also brings in HDR. Lots of movies that weren't shot in 4K or were shot on a film stock that you just can't extract 4K worth of information out of can still massively benefit from the wide gamut offered by HDR. 24-bit color isn't enough to accurately represent a lot of content. Of course this means you have to have a monitor that can do HDR, and not just that, do it properly. A lot of cheaper 4K monitors claim to support HDR, but the display can only output SDR: in this case "supporting" HDR just means the firmware can understand HDR signals and tonemap HDR to SDR so you don't have to have your player software do the tonemapping.
Does it overlap with Discreet or Softimage stuff?
Edit: Oh, and that, very importantly, ran on SGI/IRIX.
Amazing.
So that pretty much caused whoever still used it to stop. They sold to a new company who stopped that practice but I can’t think of many projects that want a managed SCM that felt there was any reason to switch to sourceforge from GitHub or gitlab after that, which is where most projects have ended up one way or another.
Their new owners now call sourceforge a place for “business software” which seems like hopefully the final stage which will bring sourceforge’s long slow decline to its end.
Edit: it looks like their latest owner (2020) is slashdot. So. I guess they will capably oversee its continued slide to irrelevance.
Not really, it's actually that Slashdot had also been sold to the same company! Just like SourceForge, under Dice.com's new management, it caused significant negative reactions among users in 2014 (that even made it to the Washington Post [0]), , and led to the creation of a Slashdot fork - Soylent News [1]. Later Dice.com sold both company to someone else again.
[0] https://www.washingtonpost.com/news/the-switch/wp/2014/02/07...
[1] https://soylentnews.org/article.pl?sid=14/02/17/0148235
Note the comments, "In Slashdot Beta, Dice rolls you!" The forced Slashdot Beta rollout was the key of the controversy.
Ditto with Blender - it's like comparing Blender with Photoshop - it makes no sense.
I used to do heavy photo editing in GIMP. I know of no one who does serious photo editing in Krita.
Wonder what could have been if GIMP would've been smarter on this.
Which is both a blessing and a curse - on the one hand, consistency, on the other hand, not welcoming to people who want to try something different.
Studios need features implemented immediately. That usually generates functional but unmaintainable solutions. Note that filmgimp/cinepaint was abandoned by studios as well as gimp developers.
What studios should have done: fund main gimp developers and hire other developers to help accelerate the development of GEGL or other multi bpp lib. What gimp developers should have done: try to merge enough of the studios changes to keep them interested.
I agree with your sentiment that some forking is preventable, but other times it isn't. Changing the fundamental design of the program tends to be one of those things that can't really be merged without causing a lot of other problems.
If you knew a way to develop software like that where everyone could get their way all the time, please let me know, we could turn that into a product and get really rich selling it to every software company.
In Japanese, there is a term for this, and it's actually borrowed from the English "my pace" (マイペース). If somebody has this attitude, you can call them a my-pace. From what I've seen, that term is always an insult: nobody ever calls someone else a my-pace as a compliment.