[Gimp-developer] Lets get rid of Fahrenheit instead

On Tue, Oct 7, 2014 at 1:57 AM, Simone Karin Lehmann <simone lisanet de> wrote:

GEGL/BABL words: operating in unbounded sRGB and converting back to the original space will give identical 
results as >operating in the original space only.

_For some operations_, like most compositing, blurring resampling, any
linear space provides the same result, for others types of operations
this is not true and I am not claiming that.

You've given a very good example for that:

x C = y F
x C = z T, where T is your "TCS" , your "temperature connection space"
is true,

T was the target/working-space *not* the connection space. The T could
not be the connection space in this example, in babl is is more likely
C (linear "sRGB") and K would be like CIE XYZ. The point of a
connection space is having a stable reference that all other units
(colorspaces/profiles) related to. T was defined as related to the
local temperature and would thus be ill-suited as a
reference/connection space.

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

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.

Elle writes well and seemingly with pleasure. 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 - I'd prefer questions to be
asked on the IRC channels (and that we found a way for such
clarifications to find their way into the development documentation
and not be lost without archive.)


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