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

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

> Please provide a specific example of an actual CMM in an ICC profile
> workflow that doesn't use XYZ for converting between RGB working spaces.

Please read simons post about matrix multiplication, in his camera
example the data never exists as XYZ.

> You falsely assume that 8-bit images are always sRGB images and that 16-bit
> integer images are probably sRGB images.

This is not being assumed, but it is a matter of fact that a lot of
buffers are in these formats and we want to deal well with them.

> > formats are crucical for integrating with existing file formats and
> > libraries;
>
> File formats that only work with sRGB images should not impact color-managed
> image editing. Advise the user to convert to sRGB.

The data needs to be loaded into a GeglBuffer with a BablFormat that
uniqely describes the color content. For 8bit sRGB with babl that has
traditionally been "R'G'B' u8", in the roadmap in babl I even
suggested that the buffers data is loaded into should be changed to be
"sRGB:R'G'B' u8" for clarity even if it will continue to mean the same
as "R'G'B' u8". And the chromaticity/working/target space should also
be set to "sRGB:R'G'B'".

> Unbounded linear gamma sRGB is not a Profile Connection Space.
>
> Idiosyncratic redefinitions of well-established color management terms
> confuses people who don't understand ICC profile color management.
>
> Idiosyncratic redefinitions of well-established color management terms makes
> it difficult for people who do understand ICC profile color management to
> communicate with the babl/GEGL devs.

There are differences between the internal implementation of a system
and the public API. Calling the bablRGB a PCS, since that is the role
it has in the internal implementation was an attempt at making you
understand the architecture, and I guessed you did understand since
you have been using the term as well. I thought you would understand
how XYZ  fills the same role in ICC. It is never called either XYZ nor
PCS in the babl code. It is better if we call it bablRGB than linear
sRGB which is an oxymoron.

> Is there any point in my demonstrating how convoluted and unworkable it will
> be to convert to unbounded sRGB whenever Y is involved? Because if there
> isn't, I don't want to waste my time.
>
> For a moment it seemed that perhaps unbounded sRGB was going to be dropped
> and we could move on to generalizing the code to use Y and XYZ taken from
> the user's chosen RGB working space
> (http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html).

I was hinting at how a given set of chromaticities wouldn't be
affecting single babl formats but change interpretation of also other
formats when given a prefix.

You seem to challenge mention of sRGB to the extent that people have
been championing linear workflows. While bablRGB will end up being an
implementation detail that is an optimization. Babl will end up having
_many_ different RGB spaces with associated grayscale format; at some
point probably also associated non-linear spaces but that will have
lower priority. Among these spaces will be a space called sRGB which
behaves like the unprefixed formats. When we have these spaces. When
we have these additional spaces - what I have suggested is that we
then mark the operations which _are_ chromaticity dependent to operate
in this space. I have also hinted at what we might want to do, or at
least which things would be possible to do - including getting rid of
all unprefixed formats, as well as the possibility that such things
could be decided dynamically. There is a lot of code in GIMP that we
intend to keep working as we move forward, the only way is by small
incremental changes while keeping things working, changing as few
assumptions as possible as move move along.

/Ø