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
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
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
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
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
gimp-developer-list mailing list
List address: email@example.com
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list