The Sad State of High Bit Depth GIMP Color Management | Hacker News Reader

The Sad State of High Bit Depth GIMP Color Management

ninedegreesbelow.com

109 pointsfoolrush42 comments

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".

It's a good thing that we have Krita.

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.

Not weird at all, same here. I find it difficult to use other programs after 10+ years using GIMP!

Lab curves for GIMP:

http://registry.gimp.org/node/24514

Sadly, it doesn't look like it's capable of working with masks and layers.

> According to this article, GIMP developers think the workflow is "wrong".

https://git.gnome.org/browse/babl/tree/docs/roadmap.txt

"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.

I have not used the other two for comparison, but Paint.Net is my go-to recommendation for casual graphics editing.

It's not Photoshop or Illustrator, of course, but all the features you need for basic photo adjustments and light-duty layout type stuff.

At a glance, Krita looks pretty nice for doing artworks from scratch.

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!".

You had one job, GIMP. One job.

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.

Who are all these people that you are talking about? :)

Because yeah, I can see how random folks on the interwebz should be listened to :)

FYI, the core GIMP team admitted long ago that GIMP's UI/UX sucks _and_ started dealing with that. See gui.gimp.org for reference.

For some context and differing opinions, see the rather long discussion thread on gimp-devel that prompted this article:

http://thread.gmane.org/gmane.comp.video.gimp.devel/26058

http://thread.gmane.org/gmane.comp.video.gimp.devel/26068

http://thread.gmane.org/gmane.comp.video.gimp.devel/26078

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.

Although reading http://permalink.gmane.org/gmane.comp.video.gimp.devel/26257 , maybe it's all just one big misunderstanding.

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.

Disclosure: I am a GEGL dev.

And this is the mail that Elle should respond to: https://mail.gnome.org/archives/gimp-developer-list/2014-Nov...

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.

I agree, the only time I tried to submit a bug report to them I got a snarky response from one dev and a ban from another.

If you're going to claim something like that, best to link to the issue in question.

(Like, 99% of the time someone complaining about being unfairly banned was being a total asshole.)

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.

It would help others to evaluate your claim.

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.

Scribus is exactly the right tool for a task like this.

Import SVG to Scribus using this workflow:

http://libregraphicsworld.org/blog/entry/getting-cmyk-colors...

Then setup CMS in Scribus and validate your output in the output preview dialog which can check for e.g. totalink coverage.

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...

[0]: http://www.darktable.org

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.

http://www.darktable.org/about/faq/

It's been how many years? And it's still 8-bit?

Maybe the GIMP needs a fork. I like it, but it's a bit crap.

That's what the CinePaint fork (originally Film Gimp) is, support for high-resolution, high-bit-depth images for "deep painting" of film assets.

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 problem does not seem to be GIMP if I understand the article correct, but the GEGL code (or the developer of it) which it relies on.

GEGL and Gimp are pretty much joined at the hip. While they're in name separate projects, they're very much developed for one another.

GEGL is developed for GIMP, and other projects. http://www.jonnor.com/2014/04/imgflo-0-1-an-image-processing... http://www.jonnor.com/2014/11/imgflo-0-2-the-grid-launched/ Disclosure: I'm a GEGL dev and the imgflo maintainer.

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.

Around 20 years :) However, development version is 16bit,32bit,linear capable for around 2 years now.

> Maybe the GIMP needs a fork

Yeah, sure. All the new developers that the team is currently missing will just _materialize_ out of thin air.

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.

[0] http://www.pixelmator.com/mac/

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.

And that route is paved by GEGL.

I guess many consider this as obvious, but I suspect that some people in this thread might not know what GEGL actually is.

Elle Stone's reply to a thread (that was started as a third party's attempt to rekindle that looong discussion):

"I agree with Alexandre. If I really do understand what Jon Nordby is saying (see https://mail.gnome.org/archives/gimp-developer-list/2014-Nov... and https://mail.gnome.org/archives/gimp-developer-list/2014-Nov...), and if the other babl/GEGL/GIMP developers really are in agreement with Jon Nordby (the babl roadmap leaves room for differing interpretations), then there is no reason whatsoever for further discussion of forking babl and GEGL to benefit GIMP."

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.

Reply on news.ycombinator.com