Re: [Gegl-developer] [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings

[Øyvind Kolås <pippin gimp org>]

On Sun, Mar 16, 2014 at 10:22 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> On 03/14/2014 10:34 AM, Øyvind Kolås wrote:
> > On Fri, Mar 14, 2014 at 2:21 PM, Elle Stone
> > <ellestone ninedegreesbelow com> wrote:
> > > But a
> > > patch to LCMS for more than four inks is surely possible.

Doing soft spectral spot color proofing, might be outside the scope of
LCMS2, or the resulting data might end up being prepared and baked
into ICC profiles using LCMS for the pre-separated output.

> > The code *experiment* linked to has nothing to do with ink limiting;
> > what I linked to is rather naive additive and subtractive color mixing
> > in a 20 band spectral color space, a little bit like how physics
> > works. But yes; as I noted it doesn't take into account subsurface
> > scattering and other things that ICC profiles try to encompass
> > indirectly.
>
> My apologies. Clearly I didn't read the code carefully enough.
>
> That's a question for the ArgyllCMS mailing list. People on that list
> profile all kinds of very odd things for specialized print reproduction,
> including rock specimens, tile samples, and oil paints. I doubt any of them
> would describe the process as "easy".

Note that spectral measurements of spot colors is also used for
standards based spot color soft proofing,
see http://color.org/CxF_test.xalter .

In a future GIMP with ink/plate targeting capabilities; it would be
reasonable to let the operator experiment with adding and
removing/rearranging inks interactively in GIMP; and some suitable
good GEGL op is used for previewing purposes (some of these options;
might already want meta data about the spot colors encoded in a passed
in profile.).

> https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html
> > for an older writeup I did on the topic of GEGL and color.
>
> I read your writeup several times over when you first posted it and also
> recently. But I'm not sure I understand it. Below is a summary of what I
> think your writeup means in terms of an image-editing workflow using GIMP:
>
> 1. When a user opens an image:
>      a. If there isn't an embedded ICC profile, sRGB is assigned. The user
> has the option to assign a different ICC profile.
>      b. If there is an embedded ICC profile, to cover cases where the
> embedded ICC profile is incorrect, the user has the option to assign a
> different ICC profile.

The same conversation to a babl managed pixel format applies on
import. Though we might be loading the data in the native
representation and only later turn it to a babl managed pixel format
(these are also spaces we can deal with ourselves on the GPU) using a
GEGL operation, or even an implicit conversion with ICC profiles
managed by a babl-extension. For a composition of multiple source
images; these ICC profile settings might vary per asset; and you want
to be able to tweak some of it after the initial import/load. When
using GIMP 2.9 in 8bit mode; implicit babl conversions keep turning
the data 32bit as explained below.

> 2. Once the initial ICC profile assignment is taken care of:
>      a. The image precision is promoted to 32-bit floating point R'G'B'A
> (32-bit floating point gamma).
>      b. The image is converted to the regular sRGB color space.
>      c. As the conversion is done using LCMS2 unbounded mode, no colors are
> clipped during the conversion. Instead, out-of-gamut colors are expressed
> using RGB values such that one or more of R, G, and B are less than 0 and/or
> greater than 1.
>
> 3. Although the image really is in the regular sRGB color space, all editing
> is done in a linear light version of the sRGB color space, which ensures
> that colors blend correctly:
>      a. If certain layer blending operations look wrong when blended using
> the 32-bit floating point *gamma* precision, the user can opt to use 32-bit
> floating point *linear* precision (32-bit floating point RGBA).

>      b. Some operations (for example painting with a brush and Gaussian
> blur) are always done using linear light, regardless of whether the image is
> converted to linear or to gamma floating point precision.

Yes, as image data flows through the GEGL processing graph - the
generated temporary output buffers end up being in the preferred
working pixel format of the operation. If all your operations used in
a pipeline are have "CIE Lab float" as their desired working/output
space, there would be only one implicit conversion to CIE Lab at the
beginning - no conversions between the operations since the data is
already in the desired format. And then an implicit conversion to the
desired reading format of for instance a PNG exporting op. Most of the
operations in GEGL generate either "RGBA float" or "RaGaBaA float"
buffers.


> 4. BABL has functions for converting sRGB to LAB, HSV, CMY, etc, for use in
> decomposing and composing. Also, babl/gegl/gimp all have functions for
> calculating the luminance of an sRGB image. Compose/decompose/calculating
> luminance are all done to/from/in linear light sRGB.

babl is intended to provide accurate and fast, conversions between a
large; and dynamically extended set of pixel formats. It provides a
way to register and describe pixel formats (color model, order of
components and data types used by components.) and has a reference
color conversion engine that goes through double precision floating
point linear light sRGB that automatically provides conversions
between the pixel formats that can be described.

On top of those capabilities; babl has extensions for direct
conversions between registered pixel formats; these conversions are
checked against the reference at runtime and benchmarked against each
other at runtime. Chains of conversions are also checked for accuracy
and speed performance. All GeglBuffers are annotated with what
BablFormat the pixels within have.

The CMYK model in babl as it stands is only intended for annotating
that a GeglBuffer contains CMYK; it likely does a really bad job at
both decomposing to inks; as well as turning inks to RGB again - it
does something though; instead of just giving you black pixels back.).
babl also has the abilitiy to deal with indexed/paletted pixels like
in GIFs. Where correct using babl for decomposing/recomposing is good
- in some cases, like CMYK we'd want GEGL operations that are not
using babl but for instance lcms2.

> 5. When linear light sRGB is required for an operation:
>      a. Certain BABL functions "undo" the regular sRGB TRC to create linear
> light sRGB.
>      b. The required editing operations are performed.

>      c. The image is returned to the regular sRGB color space.
> These "to/from linear light" BABL functions include four functions in
> /babl/babl/base/util.h: linear_to_gamma_2_2, gamma_2_2_to_linear,
> babl_linear_to_gamma_2_2, and babl_gamma_2_2_to_linear.

For c. see above, this part is wrong; though in GIMPs case when doing
editing in a "gamma" based space; it is true for applying destructive
editing operations, but for compositing the layer stack; the data is
not returned to 8bpc sRGB until the final result is displayed on
screen.,

The utility functions enumerated are part of the reference conversion
(and also used by some of the fast paths). The use in the fast paths
is not really clean; since it encourages micro optimizations in the
reference code paths; that wouldn't be detected if they cause errors..
but it has the benefit of making all users of the utility functions
faster.

> 6. Before exporting the edited image, the user can convert the image to the
> desired bit depth and ICC color space profile.

How and when export profile preferences are configured and managed is
open. If we ignore concern of ink separation workflows; it is at
export time (as well as during soft proofing) that the data would end
up being converted to the desired bit depth and ICC color profile.

> 7. At present ICC profile conversions are handled by GIMP, but in the future
> they will be handled by GEGL.

Some code will likely remain in GIMP, primarily UI related and setting
up the processing using GEGL will remain in GIMP, the actual
conversions of pixels values would be done by GEGL operations.

> A start on GEGL color management is found in
> "gegl/operations/external/lcms-from-profile.c".

A start on using lcms2 for GEGLs external color management is more
correct ;) Internally GEGL uses babl for to provide a way to carry
color (and alpha)-management meta data along with the pixels of
buffers.

> Does my description of the anticipated workflow cohere with what you've
> described? Did I get parts/all of it wrong?

More correct than wrong. My focus is more on the pipeline than the
workflow; the pipeline provides some constraints on which workflows
makes sense and which do not.

/Øyvind K.