"Clip out-of-gamut colors" check box

Yes Glenn, Lab it is.

@RichardRegal This clipping is done in most raw processors (often the only option) because it is simple and effective for what it is. How much of that has to do with range, gamut or math, it is a bit of a mystery, or at least, not simple to understand let alone explain.

If you are interested, search the forum for unbounded, unclipped, linear, HDR and scene-referred. You would find the discussion to be all over the place and sometimes controversial but if you persist you would get a better understanding of what happens behind the scenes.

As a matter of interest Glenn, can you ping me a link where I can look at the dcraw camera values myself - I’d be grateful :+1:

Iirc, the option not to clip the values was introduced shortly after the option to export 32bit float tiffs. Without that option (to export 32bit float tiffs) the data would have been clipped anyway (to the [0;65535] range of a 16bit-integer tiff when exporting to tiff.

@Andy_Astbury1 RawTherapee/camconst.json at dev · Beep6581/RawTherapee · GitHub

Here is a visual demonstration of the effect of Clip out-of-gamut colors control. It demonstrates that a particular RawTherapee tool can work well with out of gamut colors.

The starting point - Neutral profile applied to a RAW file.

+3 EV Exposure compensation is applied. This multiplies the image with 2^3 = 8. Some of the colors inevitably become out of gamut with respect to the Working Color Space (ProPhoto).

Color Toning (method Color correction regions) is applied. This multiplies the image with 1/2^3 = 0.125. The result is an image without sky because the out of gamut colors are clipped.

The control Clip out-of-gamut colors is switched off. The result is the same as the starting point.

The used RAW file is taken from PlayRaw. It belongs to Alessandro Amato Del Monte.

3 Likes

@teplit Hmm, looks well, but the blue spike in the histogram of your last screenshots, which should be not there (The spike, not your screenshot), tells me that we may have still an issue here.

@age, with reference to this:

https://bitbucket.org/agriggio/art/wiki/Pipeline

All tools before tone curve do not clip and work with unbounded data. From tone curve onwards, tools will clip (except for the output profile conversion if you use a v4 profile). To have no clipping on output, disable all those tools. Tone curve uses filmlike_clip, the other tools simply clamp

2 Likes

A rather convoluted approach, but here goes: 1) open an D7000 raw in rawproc, add a colorspace tool and assign the dcraw primaries. rawproc builds an internal profile from that. 2) save to .png with that profile embedded. 3) use exiftool to extract the icc profile’s fields from the image. Here are the relevant exiftool values:

Red Matrix Column : 0.68758 0.26758 0.01503
Blue Matrix Column : -0.03157 -0.30205 0.98991
Green Matrix Column : 0.3082 1.03447 -0.18004

These are XYZ coordinates.

1 Like

@heckflosse Yes, there is some problem here - the histograms should match according to my understanding of the tool. For another RAW file I see noticeable desaturation after performing the same procedure. The Color correction regions is not documented in RawPedia itself…

Do you think it is worthwhile to submit a bug report about that?

Which raises the question, “Where can I find a v4 ProPhoto profille?”

Not sure why you replied to me, but the RTv4_Large profile in RawTherapee is a ProPhoto v4 profile.

Common ones are

image

As @Thanatomanic said, large is the counterpart to ProPhoto.
Medium, Adobe RGB.
Rec2020 is in between and nice to use in most cases because it doesn’t include imaginary colours.

Please let me sleep about that issue first!

@teplit If you are so upset with the current state of RawPedia as documentation, feel free to lend your own expertise and help fill in the gaps. Issues · Beep6581/RawTherapee · GitHub

I find the way that ‘gamut’ is normally described/explained counterintuitive, e.g. often in non-linear squiggly Lab plots or such. On the other hand, seen linearly at their simplest, gamuts are all just plain old RGB cubes (or better different parallelopipeds).

As we are normally forced to output our images in bounded non-negative integers (i.e. 8 or 16 bits), at its simplest out-of-gamut refers to those tones that happen to fall outside the parallelopiped, which means that they are necessarily less than zero or above clipping in a given space and color channel. You could also say that they are out of bounds, out of range or off limits, it’s all the same thing.

Clearly as image data is projected from one space to another by 3x3 matrix multiplication, some tones will be pushed of bounds (err… gamut) because the math will push them above clipping or below zero in some color channel. Of course if we were to fully work in floating point we would have no upper and lower limits, therefore we would not have to worry about gamuts during raw conversion - other than for some practical reasons as mentioned upthread or for output.

That’s the gist of it, no mysteries just parallelopipeds.

I do understand this, except I think it is about mathematical convenience. I am not certain real life colour is characterized so ideally; hence the mystery. As I vaguely mentioned above, out-of-gamut and out-of-bounds are two different things. It also depends on the robustness of the transformations and the colour spaces it resides thereafter.

1 Like

Well, yes, the HVS sure works in mysterious ways and once one starts making non-linear corrections things become more complex. But linear colorimetric gamuts as we intend them in a raw conversion context are just simple parallelopipeds seen from different perspectives, and there is no mystery in that or in the linear transformations between them. Of course one may try backward somersaults to try to keep things in-gamut, but that’s a different game.

Indeed, papers are still being written about that. In any case, what do you think about this checkbox of theirs? (To stay on topic.:blush:)

I think that ideally the whole shebang should stay in linear floating point until the output. But I do realize that some important tools are not designed to work with negative values for instance, so it makes sense to make sure that the image stays in-gamut earlier than that. Making the checkbox a less prominent advanced option makes sense to me, as most users should never need it.

1 Like