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
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
