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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]