With GIMP using GEGL for image processing comes some changes in color management philosophy and approach. This is an outline of how I think the situation should be when the migration is complete; portions of this is already the case in GIMPs code. The approach outlined is one that fits well with the architectural design of GEGL.

Precision and encoding The precision of an image in GIMP is the bit-depth used for storing pixel data for layers and masks. GIMPs 8bit per component mode is optimized for dealing with sRGB and web graphics and is thus sRGB gamma encoding. Starting from 16bit precision buffers always represent linear-coded light values. We also support non-gamut bound half (16bit) and single (32bit) precision floating point. The precision does not specify a working-space, only the pixel storage precision. Each GEGL operation specifies its preferred working-space and provides a buffer tagged with a BablFormat. Optimized high fidelity conversions are performed by babl at a stage in processing where there anyways might be a copy of the data done. [1]

Import
When opening an image that has an ICC profile associated the precision would need to be bumped up from 8bit to 32bit floating point and the profile applied to the data. Untagged (8bit) data is assumed to be sRGB (babl_format("R'G'B'A u8")) and tagged accordingly. Doing this correctly is in GIMP-2.10 the responsibility of the individual file loading plug-ins. When opening legacy XCF files, GIMP should let sRGB/untagged images be treated by our new "8bit pipeline". 8bit XCFs with profiles attached need to have their precision promoted like other opened files. If an image had the wrong profile tagged (either the implicitly sRGB tagging or other) there can be a GEGL op (and GIMP-plug-in) that recasts buffer data taking the assumed "sRGB" profile and providing the correct "proRGB" profile for the data; this would be a user operation to correct an image (this would also be how one can do things like un-premultiplying wrongly exported PNGs from blender. The information about which format was wrongly assumed to be sRGB should be stored on the layer upon import.

Layer-modes
Layer modes for compatibility with 8bpc legacy XCF files (ensuring that old saved GIMP work renderes correctly) will initially be implemented by having all the legacy layer modes in a sub-menu of the layer-mode menu. From both GIMP and GEGLs point of view these modes requesting an sRGB gamma encoded (floating point) working space are distinct from new modes that work on linear light (or perhaps even CIE Lab for some).

Export When exporting from GIMP (or soft-proofing) to PNG, TIFF, JPEG etc. The color conversion would be done using lcms (or a GEGL op using lcms) to convert to a specified ICC profile. The conversion and tagging with the right profiles will be the task of the file export GIMP plug-in.

Consequences Fewer global work-flow preferences to tweak, means smaller chance that something goes wrong. All operations that should work on linear light data (like scaling, rotating, blurring, warping, smudging, compositing and more) behave correct, since it is the operation itself that dictates working space. Each op dictating working-space makes more tools behave more predictably. Since their behavior is now specified as doing math on well defined colors rather than arbitrary numbers.

1: Maybe 16bit fixed point should be ancoded with at least some bits of head/room footroom, making it possible to use !sRGB 8bpc data in 16bit integer even if the gamut of the profile is larger than sRGB.

/yvind Kols

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Mon, Aug 13, 2012 at 5:50 PM, Nicolas Robidoux wrote:

Will individual GEGL samplers be associated with a specific gamut/bit depth, or be assumed to work with a collection of them?

If only one (for all of them), has it been decided which one?

What is outlined in this post changes nothing wrt samplers in GEGL, it is only about GIMP implementation details.

/yvind K.

The future is already here. It's just not very evenly distributed
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list