On Tue, Oct 7, 2014 at 1:57 AM, Simone Karin Lehmann 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

On Wed, Oct 8, 2014 at 1:32 AM, Simone Karin Lehmann wrote:

Am 07.10.2014 um 12:27 schrieb Øyvind Kolås 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.

Your comparison is not valid, and you know that. In babl/unbounded sRGB world your input space and output space differ in a very important aspect to the PCS space unbounded sRGB: unbounded sRGB can have values < 0 or > 1, input and output don't. Whereas in ICC / XYZ world input, output and PCS have well defined boundaries, namely 0 and 1 and well defined clipping, so everything is 0 .

So, babl is used for internal color management in GEGL, while lcms2 is intended to be used for external color management for GEGL. Their roles are similar thus their architectures are similar. ICC connects devices and applications that have/operate with different color spaces. Babl connects image processing operations operating in various color spaces/pixel representations. The ProfileConnectionSpace of ICC is CIE XYZ, and the PCS of Babl is "RGBA double". A BablFormat knows how to transform its pixeldata to "RGBA double" and how to convert "RGBA double" data to its own representation. An ICC profile specifies how to transform colors to CIE XYZ and from CIE XYZ. Babl could have used CIE XYZ as its PCS and it would be transparent to its users in terms of values computed. Both PCSs are linear and unbounded and have defined transformations back and forth. The choice of something "close" to sRGB is to have efficient integration with libpng/libjpeg/gtk/v4l/ffmpeg (in addition to raster layers stored in sRGB).

Fast paths are added which are verified conversions directly between pairs of formats so that we don't have to blow a 4 component pixel up to 256bits of floating point data and churn through the code paths only intended for verifying that the fast paths actually do the right thing; the code for the fast paths (which are plug-ins to babl) is fine-tuned and makes operations that with naive code is an order of magnitude slower than memcpy just half the performance of memcpy.

The PCS is not what should be used for multiply layer mode, and neither is "RGBA float". The only forced conversion that is intended to happen is a conversion to a format well specified by babl; so that the chain of color management with conversions of source/destination ICC profiles or BablFormats is unbroken. The original color space of the photo, would be set as a target/gamut/working space. and be addressed in operations that are reliant on the RGB primaries a perhaps "target:RGBA float". Similar to how operations that need linear data with pre-multiplied alpha request "RaGaBaA float".

/Ø

On Wed, Oct 8, 2014 at 3:25 PM, Elle Stone wrote:

On 10/07/2014 08:23 PM, Øyvind Kolås wrote:

The choice of something "close" to sRGB is to have efficient integration with libpng/libjpeg/gtk/v4l/ffmpeg (in addition to raster layers stored in sRGB).

None of the above-listed libraries justify using a broken architecture that requires converting images to "sRGB as PCS":

You're not supposed to have to care about the PCS of a color management system. So I don't see how "sRGB as PCS" can broken, however enforcing linear sRGB, which is babls PCS, as a working space is something we have acknowledge to be broken in our color management architecture ever since we started talking about having support for "target" / "chromaticity" spaces.

linear sRGB being used as the PCS should have no bearing on which other formats are supported. Since the theoretical - albeit due to optimizations not true - computational path is source format -> PCS -> destination format. Redefining what "RGBA float" means destroys the ability for the babl_model("RGBA") to act as a PCS at all, this is where "RGBA double" is the Celcius from the temperature analogy. It is perhaps unfortunate that the name of the PCS as exposed in the API is "RGBA double/float..", and that the way the vocabulary has been defined that "R'G'B' u8" the non-linear variant of the PCS directly is sRGB, but this has allowed the existing code to be consistently written and be certain that both color management, data types and opacity and are in the expected format (not only color-space) at all times.

The type of BablFormat which most closely resembles what is desired to break free of sRGB with babl, is the babl-palette type formats which implement indexed mode in GIMP. Where the per palette BablModels fuel per palette BablFormats, providing a crude-non-dithering transparent conversion to and from RGBA permitting GEGL operations to work on this pixelformat transparently. The important part being the use of BablModel's with allocated data containing the palette. This despite the naming in the existing code leading you to think otherwise.

The way palette formats are addressed would not be suitable for RGB profiles and for instance the use of them for linear processing on chromaticity dependent operations, hence the "target:RGB float" prefix I used in another e-mail for the format. On the public API of babl we then need an additional call to specify what "target" or "camera2-chromaticities" or some other named RGB format is.

void babl_set_named_rgb_chromaticities ( Babl *babl,
const char *name,
double red_xyz[3],
double blue_xyz[3],
double green_xyz[3],
int white_reference);

At this stage; we would be able to control which formats are being used inside a GeglOperation, we could even add utility functions which derive the working-space for the current operation based on combinations of parameters from the op-author, and the environment (GIMP); permitting to implement various flows of data. And at some point start referring to sRGB with a different babl format.

Making it possible to have concurrent views; in separate open documents is something made harder by naming the model in the format name; that the existing palette api solves. This can be catered for by permitting to create sub-Babl *babl instances with their own namespaces and formats - where all babl formats derived from the same root Babl * are possible to use with each other.

/Ø