Re: [Gimp-developer] Attempt to summarize the discussion of my examples of what doesn't work in unbounded sRGB

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

On Mon, Apr 21, 2014 at 2:55 AM, Gez <listas ohweb com ar> wrote:
> El dom, 20-04-2014 a las 17:03 +0200, Øyvind Kolås escribió:
> > the sRGB chromaticities; or CIE Lab, or any other babl defined format.
> > With a potential future babl lcms2 extension; the original pixels
> > could even be kept in the layers raster storage.. doing so would have
> > no effect on display of the pixels or processing of them since things
> > are converted _on_demand_ to the pixel formats requested by the
> > operations. Doing this would for the user not be functionally
> > different in any way; apart from a risk of things being slower.
>
> Exactly how much work is required to create transforms from any other
> colorspace to the existing babl pixel formats?
> Is sRGB hardcoded in all the operations that flip pixel formats or it
> can be replaced without having to re-write all of them?
>
> I mean, would it be possible to create different "profiles" (note that
> I'm not talking about ICC profiles) specifying the primaries, gamma and
> white point of other colorspaces so they can be used instead of sRGB?
>
> If that was possible, it would be accessible to people like Elle who
> want to create such profiles and edit in a specific colorspace without
> the unbounded transforms and data, right?

In babl BablModel is the data types that encodes color space/TRC
aspects apart from data type in babl. One can register a new model
called "r'g'b'"; and then without much code register a new set of
named formats for different data types. One might have to manage such
formats in GIMP/GEGL code; similar to the BablFormats that represent
indexed mode pixel formats - with their associated color palettes.

After this; babl will work for all kinds of formats based on this
model - albeit a bit slowly. One might have to add architectural
changes to babl to permit implementing accelerated conversions taking
just chromacity/TRC meta-data into account. The changes/additions to
babl are similar to what would be needed for later; perhaps optional;
lcms2 support for generic ICC profile backed color models.

I wouldn't want this as a global toggle for a GIMP composition/session
though; image data in a GIMP composition can come from multiple image
sources with different source color spaces / chromacities. It would be
nice if some GEGL operations / GIMP view of channels etc. could query
what the source pixelformat of data in a GeglBuffer is; thus
operations must store the pixelformat of incoming buffers in created
buffers; compositing ops should probably forward the format of the
"input" pad. In operations where specifying the "interpolation" space
makes sense like gradient rendering; it could default to the "image
data source format" and offer sRGB based linear and gamma corrected,
CIE Lab and maybe some more.

/pippin