Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Sad State of High Bit Depth GIMP Color Management

ninedegreesbelow.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: The Sad State of High Bit Depth GIMP Color Management

#21

Post by jononor »

Sanddancer wrote: post #7
KNoureen wrote: post #5

Earlier quoted context omitted.

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.

Re: The Sad State of High Bit Depth GIMP Color Management

#22

Post by 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

Re: The Sad State of High Bit Depth GIMP Color Management

#23

Post by mschaef »

StevePerkins wrote: post #19
mschaef wrote: post #18

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 importan…

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.

Re: The Sad State of High Bit Depth GIMP Color Management

#24

Post by fl0wenol »

blt wrote: post #14

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.

Re: The Sad State of High Bit Depth GIMP Color Management

#25

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

Re: The Sad State of High Bit Depth GIMP Color Management

#26

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

Re: The Sad State of High Bit Depth GIMP Color Management

#27

Post by wlesieutre »

bostik wrote: post #22

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

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/

Re: The Sad State of High Bit Depth GIMP Color Management

#28

Post by paulmd »

StevePerkins wrote: post #19
mschaef wrote: post #18

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 importan…

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?

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.

Re: The Sad State of High Bit Depth GIMP Color Management

#29

Post by pmoriarty »

dietrichepp wrote: post #6

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 ph…

Lab curves for GIMP:

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

Re: The Sad State of High Bit Depth GIMP Color Management

#30

Post by boudewijnrempt »

ygra wrote: post #9

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…

Scribus is exactly the right tool for a task like this.
Post reply on HN