Re: [Gimp-developer] GIMP and Adobe RGB (1998)

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

On Thu, Apr 17, 2014 at 5:49 PM, Nicolas Robidoux
<nicolas robidoux gmail com> wrote:
> (Apologies if I am missing the point.)
>
> What Elle's excellent
> http://ninedegreesbelow.com/gimpgit/unbounded-srgb-what-works-what-does-not.htmlsuggests
> to me is that the designer of an operation should choose what
> color space the operations should internally work in, and convert in and
> out of it. No more and no less. My impression is that the GEGLized GIMP is
> structured so that this is feasible without too much work on the operation
> coder.

The conceptual model for the coder is the same as if the images were
converted to floating point XYZ on import;
and converted to the coders choice of input and output pixelformats
before and after. The smaller set of variation needed for the most
frequently performed conversions makes things run faster; in
particular since data isn't transformed back to XYZ but on demand
changed to the next operations desired format instead of copying where
a copy nevertheless would take place in the code.

> I have made this point in another context: Downsample through linear light,
> for example (unbounded) linear RGB with sRGB primaries or XYZ (unless
> possibly your sampler is monotone or close to monotone). And preferable
> upsample through a perceptual colorspace (like Lab or CMC or (unbounded)
> sRGB).
>
> Elle's examples simply suggest that the "broken" operations do not
> internally use a good choice of color space, and point to one better choice.

The a building block missing for doing this in GEGL with the smallest
effort (more effort on the programmer using GEGL) is two GEGL
operations using lcms2 for converting to/from arbitrary ICC profiles.
One would also want linear versions of the spaces defined by the ICC
profile. These two operations would be placed around the steps with
overriden working-space. I offer no opinion about how that would be
done in the UI. A lower level integration could permit GEGL operation
writers to specify wanting "import profile data"; perhaps linearised -
the developer of the op could then even offer some choices up for the
autogenerated property UI.

Another way to see this list; is as a list of operations that to some
degree were broken in GIMP-2.8. Where all operation happen in a
globally dictated 8bpc working-space. Possibly sRGB. Most of these are
things that should have happened in linear light but didn't. This is
what the strong internal color management of annotating all buffers
with the datas relation to linear light RGBA which is strictly defined
in relation to XYZ fixes. The cleanup and deciding the most reasonably
formats for each operation is a work in progress; parts of GIMPs UI
surely could be improved in relation to values that currently are just
preserved but not visible/actionable.

/pippin