Re: [Gimp-developer] lcms high bit depth update: now that it works, adding and improving functionality

[Elle Stone <l elle stone gmail com>]

On 1/13/13, Michael Henning <drawoc darkrefraction com> wrote:
> You misunderstood my idea. I don't want babl to get specific
> conversions for different ICC profiles; I want a generic mechanism to
> take any ICC profile and turn it into a babl format. Øyvind indicated
> that this is similar to how indexed formats already work (take a
> palette and turn it into a babl format), so this wouldn't need vast
> amounts of new code.
>
Pippin's words were "Creating custom babl formats for specific ICC
profiles is possible, and would take a similar form to how
babl/GEGL/GIMP currently deals with indexed images." I interpreted
that to mean one custom babl format per specific ICC profile, but
maybe I misunderstood Pippin.

> Part of why I suggested this is because it seems much more elegant
> than tagging a newly loaded image as, say R'G'B'A when the image is
> actually something else, like the code does now.
>
I'm not sure what you mean. The existing Gimp lcms.c code queries the
image to see what format it's in, then sends it down the appropriate
code path. It only goes down the "R'G'B'A" path if it's an RGB image
with an alpha channel.

Certainly the code can be written more elegantly. In particular, as
more color spaces are added in (as a first step, I've added in the
ability to do transforms between one gray color space to another gray
color space), the actual transformation code should be moved to a
separate function in order to avoid repetition. But anyway you slice
and dice it, there's a lot of code to write in order to give LMCS2 all
the information needed to do an ICC color space conversion.

On 1/13/13, Michael Henning <drawoc darkrefraction com> wrote:
> The idea would be to write a babl extension that links to lcms (or a
> similar lib), and uses that to do conversions under the hood.
>
I'm not sure what you mean by "under the hood". LCMS2 requires a lot
of very specific input in order to do an ICC profile conversion:

LCMS2 requires that you tell it the user-specified conversion intent
and whether or not to use black point compensation (also specified by
the user). There's also some additional CMYK "black preserving"
options that the user might want to specify for CMYK images (which
options are not currently available from the Gimp gui).

LCMS2 requires that you tell it the actual source (usually Gimp reads
this from the image itself) and destination (usually Gimp reads this
from disk) ICC profiles. Those 34 tag types that Graeme refers to do
matter when doing the profile conversion. This is especially true if
you are using absolute conversion intent because the required
information is stored and handled differently in V2 and V4 profiles.
The new tags waiting in the wings also will matter if you want to
attract the attention of the high-end image processing people.

LMCS2 also requires that you tell it what LCMS2 format the image is in
before and after the color conversion. The LCMS2 format depends on the
image color space, whether the image has an alpha channel, how many
channels total (eg n-color printing), how the channels are arranged
(RGB, RBG, etc) and the precision (8-bit integer, 16-bit integer,
32-bit floating point, etc).  You tell LCMS2 what format the image is
in by specifying the LCMS2 "formatters", one for the input image and
one for the output image (eg TYPE_RGB_16, TYPE_GRAY_HALF_FLT, etc).

The latest version of LCMS2 has 10 predefined grayscale formatters, 28
predefined RGB formatters, 47 predefined CMYK formatters, several
formatters each for XYZ, LAB, LUV, YUV, HSL, and HSV; one for indexed
images, plus a separate set of formatters for each color space for
floating point images. There's also an LCMS2 plugin for writing
additional formatters if the one you need hasn't been written yet
(unfortunately, a formatter hasn't been written for 32-bit integer
images). The existing Gimp lcms.c code is made simpler by the fact
that it only does conversions where the input and output color space
use the same LCMS2 formatter (eg TYPE_RGB_16 to TYPE_RGB_16). But as
soon as you add in converting from eg 16-bit integer grayscale input
to 32-bit floating point RGB,  or from 32-bit floating point RGB to
8-bit CMY(K) output, the code will get a lot more complicated.

Kind regards,
Elle Stone

-- 
http://ninedegreesbelow.com - articles on open source digital photography