On Tue, Oct 7, 2014 at 1:57 AM, Simone Karin Lehmann <simone@xxxxxxxxxx> 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: > > If > x C = y F > and > 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.) /Øyvind _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
