Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise

[Michael Henning <drawoc darkrefraction com>]

On Thu, Oct 9, 2014 at 8:00 AM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> To somewhat simply, ICC RGB working space profiles are characterized by:
>
> 1. The profile Red, Green, and Blue colorant XYZ values, aka "primaries".
>
> 2. The profile Tone Reproduction Curve, "TRC" for short.
>
> Right now, when a user opens a regular ProPhotoRGB image, the primaries AND
> the TRC are not what the babl/GEGL/GIMP code expects (the regular
> ProPhotoRGB TRC is Gamma=1.8). The only operations that *don't* produce
> wrong results are operations that don't use sRGB primaries AND don't
> linearize the sRGB TRC.

Yes, the current color management is somewhat unfinished and broken
with respect to importing/exporting. Nobody claimed that is was
correct. It does not implement the planned design yet.

> You can make an ICC profile using any primaries and any TRC. For example, a
> profile can be made using the ProPhotoRGB primaries and the sRGB TRC. So
> here is one way to make the current hard-coded sRGB TRC-based transforms
> between linear and perceptually uniform RGB work:
>
> Upon opening an image, use LCMS to make a profile using the user's chosen
> primaries and the sRGB TRC, and convert the image to this new profile. Once.
> Not repeatedly back and forth.

Yes, on import, we should definitely convert the TRCs. We don't do
this right now because the code isn't finished.

> And of course replace all the code that uses hard-coded sRGB primaries.

The idea is to not completely replace the sRGB code, but just add a
new code path that supports RGB spaces with different primaries. See
my remarks below.

> I have two questions about the linear-to-perceptual "babl TRC flips" code:
>
> 1. Is it acceptable to mess with a user's RGB data by keeping the primaries
> intact and "only" modifying the TRC? A user who expects their data is
> encoded using the ProPhotoRGB gamma=1.8 TRC will not fail to notice that
> data encoded using the sRGB TRC gives different results.
>
> The "babl TRC flips" code could be modified to give the user a choice of
> TRCs for encoding perceptually uniform RGB.

We were planning to include support for a choice between linear RGB w/
user primaries and sRGB-TRC RGB with user primaries, with the idea
that both a perceptual and a linear space is enough to support all the
required editing operations.

Then, many operations which only make sense with a given TRC would
specifically use that TRC. For example, downscaling might do a
conversion so it always happens in linear space.

> 2. Does the repeated linear-to-perceptual-to-linear "babl TRC flips"
> required by the current architecture impose a loss of precision? How much
> loss, after how many flips?

Yes, there is a small loss in precision. I think Daniel Sabo did some
tests to try and exactly quantify the error a while back, although I
forget the results. This certainly is a concern though, and work has
been done to minimize the error in conversions.

That being said, the operations themselves don't exactly have infinite
precision either; nearly any floating point computation has the
potential to throw away some data. The simple act of adding two
numbers in floating point can throw away data (I can provide examples,
if you're interested). To some degree you just need to live with that
fact in any floating point image editor.

> > What you are describing is exactly what I outlined API for elsewhere.
> > You would..
> > babl_set_named_rgb_chromaticities (babl, "hack", colorants..
> > and you would get what you want by having replacing all occurences of
> > "RGBA float" and "R'G'B'A float" with "hack:RGBA float" and
> > "hack:R'G'B'A float", and the same for u8 and u16.
>
>
> I'm not proposing that you use "sRGB as PCS" and then hack the code to fix
> the resulting problems. I'm proposing that you eliminate "sRGB as PCS"
> altogether. It's a broken model for RGB editing.
>
> The VFX people understood with *one* multiply example that there can be no
> universal RGB working space. The best working space depends on the artistic
> intent plus the device(s) that produced the colors, and eventually on the
> device(s) on which the colors will be displayed.

I'm not entirely clear which concept you're trying to refute in that
section. sRGB as a PCS, or sRGB as a universal working space? They're
two different concepts, and while you said sRGB as a PCS, you
arguments seem to be about sRGB as a working space to me.

Øyvind's proposal is no longer to have a universal working space. sRGB
would remain in babl as the PCS, but the results of the color
conversions would be indistinguishable from if we chose, say XYZ as a
PCS.

Ie, babl will support your suggestion (user-chosen primaries with
either linear or sRGB TRC) in addition to sRGB, instead of replacing
sRGB. Gimp/gegl will then switch to using the working space profile
instead of always using sRGB. Having sRGB still around won't make a
big difference from the user's standpoint, but it makes the code a
little nicer.

> Adobe-centric advice implies that color gamut is the only consideration when
> choosing an RGB working space. Adobe has hard-coded ProPhotoRGB primaries
> into their raw processing software. It is distressing to see GIMP follow
> Adobe's lead by writing code on the assumption that the sRGB primaries are
> suitable for editing all images.

I'll repeat that the sRGB primaries won't be the only supported
working space. You talked us out of that idea a long time ago.

> > But the "R'G'B'A
> > u8" and u16 and similar better be left alone because they have been
> > written with the assumption that their data is sRGB.
>
>
> If there is code for 8-bit and 16-bit integer images that uses sRGB
> *primaries*, that code needs to be rewritten or removed. It makes no sense
> in the context of a high end, high bit depth image editor.

I think this was a little confusing. Øyvind seems to be talking about
the large quality loss that's inherent in converting between different
color spaces while using 8 or 16-bit integers. Personally, I think we
should have the capability of having integer data in different working
spaces, and there's no technical reason why that's impossible.

> > Globally
> > switching it upon switching images does not work for copy and paste
> > between images and other forms of work where different spaces might be
> > at play.
>
>
> Copy-paste/drag-drop do require converting the pixels from the source layer
> stack's ICC profile to the destination layer stack's ICC profile. That's
> what properly color-managed image editors do. Krita does this. Surely GIMP
> can also do this.

Whether babl does the color conversions or lcms does the color
conversions will not make a difference; as long as the color
conversions are implemented properly, they will produce the same
output. So yes, we will do proper conversions on copy/paste. Øyvind
was just talking about an implementation detail that needs to be
worked out.

> > > The babl conversion to XYZ uses the sRGB D65 color space xy values and
> > > the
> > > D65 white point to convert to XYZ. This results in wrong results even for
> > > sRGB images in a D50-adapted ICC profile color-managed workflow. The
> > > right
> > > thing to do is retrieve the user's chosen profile's colorant XYZ values
> > > and
> > > ferry that to babl. This takes the place of the hard coded (and wrong)
> > > D65
> > > sRGB xy values. The equations for converting from XYZ to LAB are well
> > > known.
> >
> >
> > Babl has no XYZ format and thus in a sense no conversion to XYZ. The
> > CIE Lab implementation which came from GIMP does however contains an
> > internal conversion to XYZ; you are saying the CIE Lab code is broken.
>
>
> My apologies, I meant to type "RGB to XYZ to LAB". You can't get directly
> from RGB to LAB. You have to go through XYZ. You get from RGB to XYZ by
> using the illuminant-adapted profile colorants.

Okay, that needs fixing, then.

> Also, proper "color temperature change" code requires converting to XYZ to
> do Bradford/CATO2/etc chromatic adaptation. So a function that converts from
> RGB to XYZ really is necessary. The current temperature change code is
> hard-coded for sRGB images and although it does produce pleasing results for
> sRGB images, those results are not colorimetrically correct.

I'm not totally clear on this point. Are you saying that it produces
incorrect results for sRGB, or that it produces incorrect results for
different color spaces? I'm not too familiar with this part of the
code.

Thanks for the input.

From,
   Michael Henning