I had been waiting for a Photoshop / GIMP replacement for years, it seems that the GIMP developers dug themselves in a hole a while back with babl and GEGL and a number of good alternatives have cropped up in the meantime. My first problem with GEGL is that it seems to be the only way to reliably crash GIMP, and my second problem is that it doesn't serve to make any discernible workflow easier.
A nice workflow for photo editing involves conversion to 16-bit Lab, layers with various blending modes, and transfer curves. Due to the size of Lab, 8 bits are not enough and cause noticeable banding. Photoshop could do this back in the late 90s. According to this article, GIMP developers think the workflow is "wrong".
Krita is awesome. But, and I know this will sound weird to many people, I am now so familiar with GIMP's UI and workflow, that I find changing difficult.
"The user can create custom formats with any permutation of the components, using any of the (double float u8 u16 u8-luma u8-chroma u16 u32 and CIE Lab specific) data types in babl - or have new ones registered."
How is that plan any different from what you described?
I have a great deal of historical fondness for GIMP, dating back to the Spencer Kimball/Peter Mattis Gimp 0.5x. One of their last contributions to GIMP before moving on was to develop GTK as a part of the non-Motif GIMP 0.9x series. Gimp thus acted as a natural rallying point for would-be Gnome developers as they reacted to KDE's choice of the non-open-source-at-the-time QT toolkit. Gimp really has been very important to the open source GUI landscape....
That makes it all the more sad that Gimp development seems to have stalled, relative to other open source imaging packages. Gimp was 8bpp in 1995 and 19 years later Gimp is still 8bpp. I had had a great deal of hope for the GEGL architecture, but these days I get the distinct impression that the project picked an architecture that was beyond the ability of the available developers to complete in a reasonable amount of time. Krita, Paint.NET, and the GIMP-based Cinepaint are all existance proofs that it's possible to implement high color depth image editing in open source in less than 20 years.
Thanks for that. I'm a fairly casual user of GIMP, using it just to tweak graphics for web pages rather than "serious" creative design work. I use GIMP simply because I wasn't aware that any other acceptable open-source Photoshop-alternatives even exist.
How would you compare Krita, Paint.NET, and the Cinepaint fork for untrained web graphic users?
If all you're doing is tweaking icon-style graphics for web pages then Gimp is still a good choice. Where Gimp really starts to fall short is when you need color management, alternative color spaces, and bit-depths beyond 8bpp.
For me personally this means that I don't use Gimp for photo editing; For that, I switched to Adobe Lightroom a few years ago. It's not open source, but it's inexpensive, it works very well, and has a feature set that's closely aligned to a photographic workflow.
Every time people defend the GIMP for having a terrible user experience (just take it as a lemma; it's been debated to death elsewhere and would just clutter up the joint), they seem to inevitably trot out "But but but the GIMP is for serious image manipulation and photo work!".
i don't think that has ever been true; i have a friend who is a professional photographer, and he says gimp has never had good enough colourspace management for serious work.
From glancing over it, it seems to me like Elle Stone wants GIMP to make a rather radical shift to Do The Right Thing, while Øyvind Kolås (Pippin) values making small improvements one step at a time to avoid breaking current functionality.
This article is primarly a strawman argument, the 'architecture' which is so adamantly argued against has already been abandoned (much thanks to arguments from OP).
https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74
It has however not magically implemented itself yet.
This is somewhat recognized in the article section which starts "There is a ray of hope". The implication that the issues demonstrated will go away as a consequence of this has somehow been lost, possibly due to miscommunication.
In general, many people in the GIMP community found Elle's mails puzzling.
There have been suggestions to take the discussions to a more interactive environment - for example IRC, where most discussion happen anyway, or to the next Libre Graphics Meeting.
I'm afraid that this rather sounds like a bunch of developers who cannot take valid criticism. This is rather sad. It's sad when I see this in other projects, like Gnome.
What I did was take the snarky response and use it as a template for my response, in which case my being an asshole would've been a direct ressult of the other person being one in the first place.
If its going to change something, I have found the link. But I'm not thrilled about it, I gave up on GIMP devs a long while ago and I really don't care about them.
Only tangetially related, but is there any good way of working with color profiles and different color spaces at all in open-source software? I recently had to prepare a PDF with playing cards for printing. I was supposed to ship a PDF in CMYK with ISO Coated v2 300% (ECI). Source images from which the PDF was generated were SVG, thus sRGB. I tried using ghostscript to convert to CMYK and apply the color profile. The conversion to CMYK apparently worked, however, they told me that there are some places that have more than 300 % color. I searched all weekend for something that could use the color profile, work in CMYK and maybe something else that could actually show me where colors went out of gamut.
Somehow all that seems to only be possible using Adobe software, which makes it quite hard to supply printers with good input when restricting yourself to open-source software. Or maybe I missed a lot of things and didn't search hard enough; also possible.
While not a substitute for GIMP (because it does different things), if you're looking for "pure" photography software on linux and shoot RAW, go check out darktable. [0]
Lens corrections, advanced colourspace manipulations and all kinds of usually-applied-by-default photography tricks, in one neat package. Just don't even think about using the equalizer plugin without OpenCL enabled drivers...
I wish there were a good alternative to Lightroom for Windows. Not a priority for Darktable, unfortunately. If anybody reading this is a photographer and has the expertise to pitch in, you'd have my eternal gratitude!
> What about a Windows port?
> None of the developers use Windows, so a port of darktable to that operating system is very, very unlikely to happen.
> That being said, many things should already work, so the actual porting should be relatively straight forward. It's just that we won't do it. However, there is the "win" branch which kind of cross compiles using MinGW to generate a Windows version. It's still really buggy and might crash, kill kittens and eat your baby. You have been warned. You should read this blog post before starting any work on a port; it has an extensive discussion about this topic as well.
Is CinePaint still under development? From the sourceforge site it seems as if it was abandoned. Also, CinePaint doesn't run on Windows, which in my case is a deal breaker...
The 'other projects' part is one of the reasons why the proposed solution 'just strip all colorspace info, assume it is the same throughout entire processing pipeline' is not acceptable for GEGL, even if that might somewhat close to the typical usecase for GIMP.
Why is it that problems that are obviously due to lack of man-power in a project are more likely to cause people to call for forking the project into another one that also lacks man-power, instead of considering joining the development team to increase its man-power? The phenomenon fundamentally doesn't make sense to me.
I came to love Pixelmator [0], though unfortunately it's Mac-only. It's dirt cheap, but satisfies all my image-editing needs, and even has a vector mode.
GIMP still doesn't have adjustment layers which would be the first lesson in a Photoshop 201 class on serious photography workflows. They are very far from being a Photoshop replacement.
The issue with adjustment layers is that GIMP does not yet have a mechanism for continuous filter/plugin evaluation and it may not yet be fully thought out: so what does the layer mask do in this case, just a wet/dry mix, some other plugin-specific parameter per pixel?
Also, if we're going this route it might make sense to have adjustment layers attached to a parent layer where they apply (as descendants), and then be able to reorder them within.
And if we're going that route, they need to get the full hierarchy model for layers in there first.
I had some interesting email conversations with GIMP developers in the 1990s. I can't speak for now, but at the time it was a "classical" open source project. AKA, it existed to scratch the developer's itch. It was never intended to compete with another product like Photoshop or any other product.
A nice workflow for photo editing involves conversion to 16-bit Lab, layers with various blending modes, and transfer curves. Due to the size of Lab, 8 bits are not enough and cause noticeable banding. Photoshop could do this back in the late 90s. According to this article, GIMP developers think the workflow is "wrong".
It's a good thing that we have Krita.