Re: [Gimp-developer] suggestions

On 04/04/2016 05:36 PM, C R wrote:

Only so many hours in the day. For RAW processing Darktable works fine.
Back when I switched from Photoshop, RAW editing was still done via
plugin, and if you were serious about it, you'd do it in Adobe Lightroom.

Back when I switched from PhotoShop, I had already realized that the free/libre dcraw from the command line did a better job than ACR. As my workflow starts with a scene-referred rendition, whatever extras Lightroom might have provided were irrelevant.

Of course today's free/libre interpolation algorithms are considerably advanced beyond what dcraw provides.

When the deal is "free" it's hard to take such opinions seriously. Yes,
I've heard a lot of ranting too. It sounds more and more like noise when
they show you pretty grim portfolio pieces done in Photoshop. As if
doing something in their editor of choice automatically made them more
professional somehow.

As the GIMP vision statement seems to imply that supporting advanced workflows is central to the goals for GIMP, it's hard for me to understand why the ability to edit in GIMP using RGB working spaces other than sRGB isn't already part of the code.

On the topic of nodes though, have you tried Natron?

No. I haven't had the time, though it's on the "to do" list.

Have you tried PhotoFlow? I believe PhotoFlow uses nodes. It's a non-destructive raw processor/image editor that also runs as a GIMP plug-in.

    I can (and do) patch and build versions of GIMP that work in
    Rec.2020 or other working space(s) of my choice. Most people can't
    or won't do this.

How hard was the patching? Is it really one or the other only?

Keeping the patches up to date with babl/GEGL/GIMP from git is tedious.

Yes, it's really one or the other because in babl/GEGL/GIMP code the RGB values for Y and XYZ are hard-coded to sRGB instead of using colorant values from a user-chosen RGB working space.

Partha very kindly provides builds for my patched GIMP for Windows ( But for Linux you have to compile it yourself (

    I've been using my patched high bit depth GIMP a lot in the last
    year. So obviously I enjoy using GIMP, and also I like the results
    I'm getting. Otherwise I wouldn't be here pestering the devs (yet
    again) about adding full support for editing in working spaces other
    than sRGB.

Have you tried the development build?

I keep up with babl/GEGL/GIMP from git in a "default GIMP" prefix that I use for filing bug reports. For actual editing I use my patched version of babl/GEGL/GIMP compiled in a separate prefix. I update the patches every month or so.

In development build (gimp-edge)

Image > Precision > Linear Light

The other option is "Perceptual Gamma (sRGB)"

Those would be the "babl flips" that allow the devs to decide whether any given editing operation should be done on linear gamma RGB or on perceptually uniform RGB, with "perceptually uniform" hard-coded to be the only approximately perceptually uniform sRGB TRC.

The babl flips really could be very useful, especially if all editing operations provided the user with a choice between linearized and perceptually uniform RGB.

But for now the babl flips are still a bit of an impediment as sometimes the default "linear vs perceptual" choice is not radiometrically correct. For example Curves and Levels by default are done on perceptually uniform RGB, which unfortunately produces radiometrically *in*correct results.

Not sure if this is what you are after, but I thought of you when I saw
the feature. :)
Note also up to 64bit precision now.

GIMP's 64-bit precision option is to allow for importing from/exporting to 64-bit precision files such as FITS files.

All internal GEGL processing is done at 32-bit floating point precision.

The only thing you accomplish by choosing to *edit* at 64-bit precision is that you'll very quickly fill your available RAM and GIMP will slow waaaaay down.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]