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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I'm posting to the original thread. Pippin had started a new thread:

On 10/07/2014 06:27 AM, Øyvind Kolås wrote:> On Tue, Oct 7, 2014 at 1:57 AM, Simone Karin Lehmann<simone@xxxxxxxxxx> 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 problems for

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.

Elle Stone

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

gegl-developer-list mailing list
List address:    gegl-developer-list@xxxxxxxxx
List membership:

[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux