Re: [Gimp-developer] suggestions

[Elle Stone <ellestone ninedegreesbelow com>]

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 
(http://www.partha.com/). But for Linux you have to compile it yourself 
(http://ninedegreesbelow.com/photography/patch-gimp-in-prefix-for-artists.html).

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

Best,
Elle