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

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

On Sat, Oct 4, 2014 at 2:46 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> Based on the groundless premise that editing operations should produce the
> same results when performed on the same colorimetric colors, ..

No; but same parameters for same input colors producing same results
is considered desirable behavior. Predictable interfaces are nice
interfaces.

> ... the BABL/GEGL/GIMP architecture specifies that:
>
> 1. sRGB should be the universal RGB working space.

No.. but GEGL stores the pixel-format/color-space of a pixels values
along with the pixel as it is passed around (along with the whole
GeglBuffer actually). Internally GEGL doesn't use ICC for this but
BablFormats which represents a subset of possible ICC formats. The
"profile connection space" used by babl is linear RGB with sRGB
primaries, since this permits very low overhead for doing operations
in this color space; a color space which also is suitable for these
operations (most layer compositing modes and blurring). The intention
is to keep using babl for internal buffer management and integrate
well with an external color management system for interacting with the
more complex things ICC profiles express.

> 2. Developers should decide whether an operation is done using linear RGB or
> RGB encoded using the "almost perceptually uniform" sRGB TRC.

Almost, developers decide which pixelformat is appropriate for their
operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale
formats as well as formats used with digital video with different data
types; currently the set of babl formats. The problems you've pointed
out with for instance multiply have led to a consensus that we will
also need a target-space/working-space choice, perhaps two; one linear
and one more perceptual.

The logic involved in configuring the pixel format inputs/outputs of
each operation could possibly be made more configurable (in GEGL, not
necessarily work to be done by the implementor of the op), thus also
enabling mostly conversion free processing modes of operation like
what you seem to want when you reduce babl to only deal with precision
conversion.

/pippin