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.