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

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/05/2014 12:49 PM, Øyvind Kolås wrote:
> sure GIMP/GEGL is
> not there yet, but for a GIMP 2.10 release it is good enough. (2.10s
> stated goal is being to be able to do what 2.8 does; but with GEGL
> inside - the higher bitdepths and such are bonus.).

The time table for implementing new features is irrelevant to why 
BABL/GEGL/GIMP intends to use a broken architecture.

> Most current named BablFormats are immutable - in the same ways ICC
> profiles are treated as immutable. Changing the meaning of "R'G'B'A
> u8" or "Y'CbCr u8" and similar will break color management for
> operations providing integration with various image loaders/video
> codecs/webcam/GUI that already exist.

Whether or not device-specific code makes sense in a color-managed 
editing application isn't relevant to why BABL/GEGL/GIMP intends to use 
a broken architecture.

> GEGL strives to bring linear light editing all the places it makes
> sense; this will hopefully be a better experience than 8bpc sRGB.

Linear RGB data manipulation does require high bit depth image editing. 
But linear RGB data manipulation is not facilitated by an architecture 
that converts the user's color data to "sRGB as PCS". Precisely 
*because* the primaries used to encode RGB data do make a difference in 
the results of editing operations, the user must choose the appropriate 
primaries for the task at hand.

Two justifications have been given in support of the BABL/GEGL/GIMP 
architectural requirement that images be converted to "sRGB as PCS":

Justification 1: A forced conversion to "sRGB as PCS" meets a "desirable 
interaction goal" that sliders produce the same results when operating 
on the same XYZ colors.

This "desirable interaction goal" betrays a failure to understand the 
nature of RGB image editing. The interactions of real world light and 
colors are only partially preserved in RGB data. So necessarily RGB data 
is color data that is encoded using RGB primaries that are appropriate 
to the editing task at hand.

Hacking the broken architecture to fix specific broken editing 
operations undermines the stated goal that sliders should produce the 
same results when operating on the same XYZ colors. So this 
justification has already fallen apart.

Justification 2: A forced conversion to "sRGB as PCS" makes possible 
fast path conversions from "sRGB as PCS" to XYZ, LAB, YCbCr, etc.

A fast path conversion that depends on mangling the artist's data by 
converting it to "sRGB as PCS" is just a fast way to get to a bad 
results out of a broken architecture.

Any processing advantage provided by using hard-coded sRGB parameters 
will be swamped by the processing load imposed by hacks that convert 
from "sRGB as PCS", to the artist-chosen RGB primaries, and back again 
to "sRGB as PCS".

The "fast path conversion" argument also has fallen apart.

> With what
> has been proposed as a solution for ops that need to use a
> target/working RGB space is that the operation would ask for a special
> symbolic babl format or similar; and GEGL/babl does the rest behind
> the scenes.

You've conceded that your architecture is broken to the point where you 
must hack in fixes for multiply. That's the first of many such hacks to 
come:

Retrieving the artist's original channel data? Hack.

Display-referred editing using the negative channel values that will be 
produced by a forced conversion to "sRGB as PCS"? Hack.

Using the Levels gamma sliders? Use the Red/Green/Blue Levels 
input/output sliders? Hack, hack.

RGB data doesn't 100% capture the way light and color behave in the real 
world. Rather RGB data necessarily is encoded using different primaries 
for facilitating different editing goals.

Think about the implications of Rick Sayre's comment on non-orthogonal 
transforms to XYZ:
https://groups.google.com/forum/?_escaped_fragment_=msg/academyaces/9b4VuqPcOHQ/Hg8c9V6flOYJ#!msg/academyaces/9b4VuqPcOHQ/Hg8c9V6flOYJ

What Sayre says cuts to the heart of why an architecture that requires a 
conversion to "sRGB as PCS" is broken and can't be fixed.

With respect,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography