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

[Elle Stone <ellestone ninedegreesbelow com>]

I'm posting to the original thread. Pippin had started a new thread: 
https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00010.html

On 10/07/2014 06:27 AM, Øyvind Kolås wrote:> On Tue, Oct 7, 2014 at 1:57 
AM, Simone Karin Lehmann<simone lisanet de>  wrote:

> > BTW, I've noticed, that although Elle always gives equations or real
world examples and images to prove her >statements, you don't. So, I'd 
like to ask you for such a mathematical equation or real world example 
for your statements.

Simone, thanks! for contributing to the discussion.

> Lets keep T out of the picture for the moment and focus on the others,
> the current state of babl. It is an environment where all temperatures
> are tagged with a unit, and the things operating on these values
> always check the units of incoming data, converts to their preferred
> unit; and pass data on annotated with which unit the temperature has.
> This is how babl works, all computations gets a unit associated with
> it. If it is computations that need to compare energy levels, K would
> be used. Doing this is what for instance mitigates
> http://www.4p8.com/eric.brasseur/gamma.html problems for
> scaling/blurring.

Brasseur shows why scaling needs to be done on linearized RGB. The 
defining primaries are irrelevant. Nothing in Brasseur's demonstrations 
provide any justification for a forced conversion to "sRGB as PCS".

> Babl provides the vocabulary and set of _defined_
> units to be able deal with the multitude of temperature units/pixel
> formats in use by different algorithms and libraries.
>
> The original plan was to convert from whichever local units are being
> used to C, K or F the limited set of known format of babl at import
> time. So that we only would need to be able to transform other types
> of units like A,B or T into one of C, K or F at the beginning, and
> potentially convert back to some other format after having done
> computations on the data purely with C, K or F.
>
> Elle has pointed out that there are _some_ operations we are doing
> which actually depends on "subjective celcius" or T, how far from
> freezing towards water would be at a given temperature locally.
> Perhaps a thermostat where the sensitivity for the hysteresis is
> computed in T based on T yielding a value in T (or C/K doesn't
> matter). If we have stripped away the knowledge of where we are (what
> T really means) we are unable to do that computation. And at the
> moment we are using C here instead which is broken "everywhere but at
> sealevel", where all C == T and linear sRGB == linear camera space.
>
> Then there is two approaches to solving this - both would give the
> same result, one is to add the ability to express for our thermostat
> op that it wants to receive/operate on/produce T instead of in C in
> addition to the already existing units.
>
> The other approach is to replace all usage of the unit C with T also
> for operations where C and T yield the same result (multiplication in
> the temperature case, addition in the color case). For many parts of
> GEGL doing this change is a way to preview what the result of doing
> the above approach would result in, other parts of GEGLs universe that
> use the unit C break if its data blindly will be treated as T, or it
> gets fed data which in T treating it as C.
>
> The set of pixel formats currently in babl are by
> implementation&definition references to unchanging color spaces and
> representations - this is how babl is built with linear sRGB as it's
> connection space; and this is how ICC works with XYZ as it's
> connection space. A babl format like "R'G'B'A u8" (actual sRGB 8bit)
> is an as immutable entity as an ICC profile is in ICC, one can
> consider babl formats "light weight ICC profiles" - and part of the
> foundations for being rigid with treatment of color in GEGL - which is
> why I compare refactoring sRGB out of babl to banning Celcius.
>
> Babl is being used in GEGL for all copies of pixel data, the copies
> gets the unit of both source and destination - when these match it is
> a plain copy (and in many cases - not even a copy). Thus chains of
> operations asking for the same unit - means no conversions in-between.
> If we had T in addition to C,K. then it could be possible to enforce
> more operations using T in the code which hosts the gegl ops.

This somewhat tortured temperature conversion analogy reads like 
obfuscation trying to disguise itself as logical justification for a 
broken architecture.

> Personally I prefer
> writing documentation to writing email, but neither of those are
> pleasurable like writing code. You can however take my word for how
> babl and GEGL works - the code is a real world example, and when
> people do not understand how things work.

A standard polemical ploy is to claim that someone doesn't understand 
how something works.

I do understand how babl/GEGL works. There is a difference between 
"understanding" and "agreeing".

Any architecture that requires hacks to make basic editing operations 
work is broken. You can dress it up and make it sound like the hacks are 
just extending existing functionality. But in this case it's obvious 
that the reason for the hacks is to fix something that is only broken 
because of an architecture that intends to use "sRGB as PCS".

Since April I've tried to explain why Pippin's architecture is broken. 
I've used logic, examples, equations, pictures, long explanations, short 
explanations, and other people's explanations.

GIMP is an important part of free/libre editing software. People have 
been waiting for many years for GIMP to offer high bit depth image 
editing. At the moment it looks like what they are going to get is 
broken high bit depth image editing.I'm not going to try again.

Respectfully,
Elle Stone

For anyone who is interested, here are links with information on how 
"sRGB as PCS" mangles RGB color data:

http://nbviewer.ipython.org/github/colour-science/colour-website/blob/master/ipython/about_rendering_engines_colourspaces_agnosticism.ipynb

http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html

http://ninedegreesbelow.com/photography/display-referred-scene-referred.html#unbounded-sRGB-broken-model

http://ninedegreesbelow.com/photography/unbounded-srgb-multiply-produces-meaningless-results.html

http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html

https://bugzilla.gnome.org/show_bug.cgi?id=737778