I sat down recently and spent a marathon session editing a whole bunch
of images using GIMP 2.9 to see where the bottlenecks and useability
problems might be.
Although I do edit in other RGB working spaces, for this particular
editing session all the images were in-camera-saved sRGB jpegs. The
finished pictures images are on this page, if anyone is curious:
http://ninedegreesbelow.com/galleries/niagara-falls.html
I found GIMP 2.9 to be very useable. I did keep running into the same
useability issues over and over again, having to do with things like the
file export dialogs and problems with some of the transform tools. But
none of the issues were show-stoppers, rather minor inconveniences and
annoyances that do add up when editing a whole bunch of images in a row.
"Useability" implies "for what workflow" and also implies "as measured
against which other image editing applications". I'm comparing GIMP 2.9
with PhotoShop CS2, Cinepaint, and Krita 2.9. Several versions of PS
have been released since CS2, but CS2 is the only version of PS that
I've ever used.
My comparison is based on a strictly RGB workflow (I don't use CMYK and
seldom use CIELAB) that depends on:
1. Using masks and layers in a high bit depth image editor.
2. Being able to switch between linear gamma and perceptually uniform
versions of the same RGB working space, depending on the editing task at
hand.
3. Being able to soft proof to an output color space (doesn't apply when
the editing and output space are both sRGB).
4. Being able to manipulate Levels and Curves when in a linear gamma
working space.
PhotoShop: PhotoShop CS2 was OK at 1 and 2 (if you call PS's odd "15+1"
bit editing "high bit"), good for 3, and terrible at 4 because the
PhotoShop Curves and Levels dialogs only worked in 8-bit chunks,
regardless of the bit depth of the image itself.
Between PhotoShop CS2 and GIMP 2.9, for my workflow GIMP 2.9 is better.
Of course it would be nice if GIMP supported editing in CMYK and CIELAB.
But I'm speaking from the point of view of a strictly RGB workflow that
uses linear gamma color spaces.
Here's what PhotoShop CS2 had, that I wish GIMP had:
* Adjustment layers, so that Curves, Levels, Channel Mixer, etc could be
applied as an adjustment layer without having to modify an actual pixel
layer. This made going back and tweaking the adjustment layers very easy
to do, without having to redo an entire layer stack.
* A color-managed color picker.
Cinepaint: When I switched to Linux (when Windows Vista was released), I
thought Cinepaint would replace PhotoShop. Well, Cinepaint offers high
bit depth image editing with masks and layer. But the Cinepaint Curves
dialog is too small to use for linear gamma image editing. Actually it's
too small to use, period. There's a whole lot of basic editing
functionality that's missing from Cinepaint. And I never did figure out
how to paint on a mask using Cinepaint.
I wish GIMP had something like Cinepaint's soft proofing dialog, which
can be applied on an image-by-image basis from a very convenient
drop-down menu (no need to open the Color Management Setting dialog).
Krita 2.9: Krita is a digital painting application. On the one hand,
painting in Krita is a joy. Krita has color-managed color pickers and
can do lens blurring, which is something that GIMP can't do. Krita's
Color blend mode works better than GIMP's. On the other hand, Krita's
Curves and Levels UI are very small and not very easy to use. And GIMP
offers a whole lot of photographic image editing functionality and some
important color management functionality that Krita doesn't have, at
least not yet. Fortunately, no one needs to choose between Krita and
GIMP. They complement one another very nicely.
The babl sRGB TRC linearizing code: The images that I edited were sRGB
images to begin with, and I used the sRGB primaries for editing the
images, converting the image back and forth between linear gamma sRGB
and perceptually uniform sRGB, depending on what editing operation I
wanted to use next (ie to perceptually uniform sRGB for adding RGB noise
to act as a kind of "dither" when changing the precision from 8-bit
integer to 32-bit floating point, to linear gamma sRGB for color
modifications and for converting to black and white, and so forth).
However, I wasn't using default GIMP 2.9. In my opinion, the babl sRGB
TRC linearizing code is flatly unuseable in its current form. It has the
potential to be incredibly useful, but it's not there yet. So I made a
change to the babl/babl/base/util.h file to disable the babl linearizing
code, and then just used ICC profile conversions to convert the images
back and forth, as needed, between linear gamma and perceptually uniform
versions of the sRGB color space.
See
http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html
for reasons why I think the babl linearizing code isn't ready for
"production" use. It's mostly a case of "UI" issues.
If the babl sRGB TRC linearizing code were disabled or made optional
instead of mandatory, maybe via a GIMP Color Management Setting, it
seems to me that GIMP 2.10 could be released today and a whole lot of
people who've waited for high bit depth GIMP would be very happy.
Editing functions that use hard-coded sRGB Y and XYZ values would give
wrong results for anyone editing in wider gamut color spaces. But the
same is true for GIMP 2.8 and also for a few other image editors, so
that doesn't seem like a showstopper.
Elle
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
