On Wed, Oct 8, 2014 at 1:32 AM, Simone Karin Lehmann <simone@xxxxxxxxxx> wrote: >> Am 07.10.2014 um 12:27 schrieb Øyvind Kolås <pippin@xxxxxxxx> >> 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". /Ø _______________________________________________ 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
