[Gimp-developer] GIMP, GEGL, storage precision and color-management

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

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 Kolås