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

[Øyvind Kolås <pippin gimp org>]

On Wed, Oct 8, 2014 at 1:32 AM, Simone Karin Lehmann <simone lisanet de> wrote:
> > Am 07.10.2014 um 12:27 schrieb Øyvind Kolås <pippin gimp org>
> > 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 <= x <= 1. The interesting point 
> is, that the math really differs between your world "unbounded sRGB, no clipping" and "defined boundaries, 
> clipping".

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

/Ø