Re: [Gimp-developer] Three questions about opening an image and converting it to linear light RGB

[Elle Stone <ellestone ninedegreesbelow com>]

On 04/06/2014 05:23 PM, Gez wrote:
> El sáb, 05-04-2014 a las 12:21 +0200, Nicolas Robidoux escribió:
>
> > It is my very strong opinion that values should not be clamped by
> > default.
>
> > If you are writing an operation (a "node") that is broken by negative
> > or values breaks, do not clamp the input and output without carefully
> > considering the possible impact on the entire toolchain.
>
> > Very very carefully: Clamping values can have surprising side-effects
> > (as the Blender community apparently discovered through experience).
> >
> > If it is likely that your operation will be fed, for example, negative
> > values, try to write your operation so it does something sensible with
> > them.
> >
> > Clamping should be a last resort.
>
> Not even a last resort. Clamping unbounded values will destroy the
> excess gamut that the unbounded transform is supposed to keep.
> Blender works in scene referred linear (from 0 to infinity) and clamping
> is used to restrict the values to the display-referred limits when the
> user needs it.
> In Blender chromaticity is never out of bounds (unless you explicitly
> fed a node with an ilegal value, like a negative value), it's just
> intensity. For instance, if your red channel goes beyond 1.0 it never
> means "redded than red".
>
> We agree: values should not be clamped.
> My question question (and I think also Elle's question) wasn't about
> whether those values have to be clamped or not, but about the impact of
> values beyond the display referred bounds resulting from the forced
> conversion to unbounded sRGB.

Yes, that was part of what my question was about.

When shooting raw, colors can be captured that exceed the very small 
sRGB color gamut unless you use floating point unbounded mode ICC 
profile conversion from the camera input profile to sRGB.

I've been experimenting with converting interpolated-from-raw camera 
images from my preferred RGB working space to the unbounded mode sRGB, 
to see how editing results compare when done in these two vastly 
different RGB color spaces.

One problem with converting camera images to unbounded mode sRGB is that 
there's still a lot of clipping and clamping code in GIMP that needs to 
be "unclipped/unclamped".

Otherwise unbounded mode sRGB image editing fails whenever an image 
color hits 0.0 or 1.0, which happens all the time for images that are 
the result of shooting raw.

For example, the following GIMP layer blend operations should be 
unclamped; the files are all in gimp/app/operations with obvious file names:

grain extract
grain merge
addition
subtract

Removing the clamping code makes makes these blend modes give the same 
visual results in my preferred RGB working space and in the sRGB 
unbounded mode, assuming of course that the user chooses the proper 
precision for the blend mode.

For a couple of test blends, after converting back to the original color 
space and taking a difference, the resulting images are not just 
visually the same, but completely or almost completely identical on a 
pixel by pixel basis.

I'm still testing the other gimp/app/operations layer blend modes. But 
probably *all* clamping code should be removed from *all* layer blend modes.

Elle's two cents worth