
The Sad State of High Bit Depth GIMP Color Management - foolrush
http://ninedegreesbelow.com/photography/sad-state-of-high-bit-depth-gimp-color-management.html
======
dietrichepp
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.

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

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

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

~~~
StevePerkins
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?

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

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

:(

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

------
unhammer
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/26058)

[http://thread.gmane.org/gmane.comp.video.gimp.devel/26068](http://thread.gmane.org/gmane.comp.video.gimp.devel/26068)

[http://thread.gmane.org/gmane.comp.video.gimp.devel/26078](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.

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

------
jononor
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](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.

~~~
schumaml
And this is the mail that Elle should respond to:
[https://mail.gnome.org/archives/gimp-developer-
list/2014-Nov...](https://mail.gnome.org/archives/gimp-developer-
list/2014-November/msg00006.html)

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.

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

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

~~~
rho_away
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.)

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

~~~
schumaml
It would help others to evaluate your claim.

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

~~~
prokoudine
Import SVG to Scribus using this workflow:

[http://libregraphicsworld.org/blog/entry/getting-cmyk-
colors...](http://libregraphicsworld.org/blog/entry/getting-cmyk-colors-from-
inkscape-to-scribus)

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

------
bostik
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](http://www.darktable.org)

~~~
wlesieutre
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/](http://www.darktable.org/about/faq/)

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

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

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

------
M4v3R
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/](http://www.pixelmator.com/mac/)

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

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

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

------
schumaml
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...](https://mail.gnome.org/archives/gimp-developer-
list/2014-November/msg00018.html) and [https://mail.gnome.org/archives/gimp-
developer-list/2014-Nov...](https://mail.gnome.org/archives/gimp-developer-
list/2014-November/msg00023.html)), 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."

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

