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

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/10/2014 07:49 PM, Øyvind Kolås wrote:
> On Sat, Oct 11, 2014 at 1:18 AM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:

> > So I have two specific questions. The first question is about
> > converting to LAB. The second question (which I haven't asked yet) has to do
> > with Y.
>
> We will try to do what makes sense and helps us achieve what we need
> to achieve efficiently; while keeping what works well, working well.

The above statement is devoid of content. It serves to dismiss my 
specific questions about why you want to keep hard-coded sRGB XYZ and Y 
in a color-managed workflow.

> > "sRGB as PCS" is linear gamma unbounded sRGB. I think it's reasonable to ask
> > why a conversion to unbounded sRGB should be involved in a conversion from
> > User_RGB to LAB.
>
> For the same reason XYZ is involved (or not, depending on how the CMM
> does it) in an ICC workflow.

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.

> > > Existing code written with assumptions of sRGB, whether in GIMP and
> > > GEGL that we control or in XPM, GTK, GDK, or elsewhere that has sRGB
> > > assumed will continue to work. We take the existing architecture which
> > > is following general guidelines of assuming sRGB where none is
> > > specified.

A guideline for dealing with images that don't have embedded ICC 
profiles makes an appalling bad guideline for writing a color-managed 
image editor.
> This is not about how images with no embedded profile are handled.
> sRGB derived 8bit (and to a lesser degree 16bit) formats are used for
> many other things than images with no embedded profile.

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

> These pixel
> 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.

Accurate UI colors is a desktop color management issue, entirely 
irrelevant to programming a color-managed image editor.

> and we want these conversions to be as fast as possible -
> even if it might have an impact on the conversion speed for CIE Lab,
> though that does not have to be the case either. Choosing any PCS
> *but* linear sRGB into a PCS  would tend to make these important
> conversions slower.

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.


> > I can move on to my question about Y and unbounded sRGB. But I still don't
> > understand why unbounded sRGB should be involved in a conversion from
> > User_RGB to LAB.
>
> We will do what makes most sense and is neccesary when we get there, I
> suspect each RGB model with have an associated Y and YA model. Due to
> how the existing BablModels interact with components and vocabulary
> used to address them in babl; potential support for different TRCs is
> even vaguer; we'll know when we have more code.

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.

> Maybe we have more code by the time of LGM, if not that would be an
> excellent place to elaborate;

As I have indicated before, the invitation is very kind. But not 
everyone is able to drop other obligations and go to LGM.

> until then I prefer IRC.

Twice I tried to discuss problems with unbounded sRGB on IRC. It was 
neither pleasant nor productive.

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).

However, given Pippin's latest explanations of how things will be done, 
I'm not sure there's any point in my continued involvement with GIMP 
development.

Kindest regards,
Elle Stone