Sent: 2010-08-13 13:35:50 UTC (over 1 year ago)

From: Øyvind Kolås

Lab conversion, GEGL, RGB space, Illuminant

permalink

On Fri, Aug 13, 2010 at 9:06 AM, wrote:
> On 13 August 2010 02:57, James Cox wrote:
>>> You don't need to worry that the sRGB gamut is rather small since,
>>> because GEGL is using float, it can represent values outside the gamut
>>> as less than 0 or greater than 1.
>>
>> That sounds good in theory, but there will be some very sharp edges in
>> practice.  What does the UI for the curve tool look like when possible
>> values are -FLOATMAX to +FLOATMAX.  What does the contrast tool do with
>> values above 1.0.  When I blend some layers with multiply mode they can
>> only get darker right?
>
> scRGB actually does define a range, -0.5 to +7.5, according to
> wikipedia, so tools like the levels dialog are not totally in the
> dark.

That is just due to the encoding chosen, (fitting in 16bit) GEGL uses
normal IEEE floats just like EXR and thus has the range -FLOATMAX to
+FLOATMAX supporting HDR buffers with huge range. Thus the "native"
pixel format used by GEGL isnt directly scRGB, but IEEE floating point
RGB(A) with linear light and primaries like in sRGB.

Some additional comments about color management in GEGL, confirming
what has already been stated/suggested. GeglBuffers have a specified
pixel-format, as defined by babl, babl's pixel formats are (at least
supposed to be) well defined and accurate conversions between both
precisions and color models. Thus once data is in a babl governed
pixel format the color values should already be well defined. If the
color space of a source image is in a device-dependent color space it
either is converted upon load to for instance "RGBA float" or a
dynamically created babl pixel format with an attached/referenced ICC
profile and lcms2 powered conversions would be used.

GEGLs image processing is intended to all operate in device
independent color spaces, no matter which camera you took a picture
with gaussian blurs, color adjustments etc, should behave the same.
For many operations "RGBA float", linear light RGBA in 32bit floating
point is good. For other operations "RaGaBaA float" is good this being
the same as "RGBA float" but with pre-multiplied alpha, this is used
by most compositing operators. Some operations might prefer to operate
in (and generate) "CIE Lab float" buffers, like the color layer mode.
If the previous operation generated buffer data in the preferred
format of our current operation the conversion will be a no-op or babl
will fall back to a memcpy (in cases where direct access to underlying
tiles is not possible). The net-effect of this is that GEGL should
provide a color managed result that can ultimately be
converted/separated according to a target profile.

To force operation in a non-color managed, paint by numbers-mode you
would have to force the format of a buffer, casting a device-dependent
pixel format to "RGBA float" before the operations - and casting it
back to the device-dependent format after the device-dependent
processing is done.

--
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer