"Clip out-of-gamut colors" check box

Just a comment about the clipping default. In another thread I couldn’t figure out why local edits in RT couldn’t recover highlights in any meaningful way. Turned out it was that very checkbox that cut off all that data early in the pipeline.

1 Like

It’s my educated guess, I’d be happy to learn from those who actually know.

Here is what the Adobe Standard dcp is for the Nikon Z7. Note that the FM have no negative figures? That’s desaturation ensuring that no negative values are generated in XYZ, which they then make up in the LUTs. Also there is no ‘ProfileToneCurve’ data:

{
“UniqueCameraModel”: “NIKON Z 7”,
“ProfileName”: “Adobe Standard”,
“ProfileCopyright”: “Copyright 2017 Adobe Systems, Inc.”,
“ProfileEmbedPolicy”: “Allow copying”,
“ProfileCalibrationSignature”: “com.adobe”,
“CalibrationIlluminant1”: “StdA”,
“CalibrationIlluminant2”: “D65”,
“ColorMatrix1”: [
[ 1.128400, -0.491100, -0.060800 ],
[ -0.606200, 1.422800, 0.196000 ],
[ -0.087700, 0.160500, 0.811700 ]
],
“ColorMatrix2”: [
[ 1.040500, -0.375500, -0.127000 ],
[ -0.546100, 1.378700, 0.179300 ],
[ -0.104000, 0.201500, 0.678500 ]
],
“ForwardMatrix1”: [
[ 0.541800, 0.306300, 0.116200 ],
[ 0.334400, 0.629200, 0.036400 ],
[ 0.182200, 0.000500, 0.642400 ]
],
“ForwardMatrix2”: [
[ 0.445100, 0.349200, 0.170000 ],
[ 0.229200, 0.719200, 0.051600 ],
[ 0.079400, 0.003100, 0.742600 ]
],
“ProfileHueSatMapDims”: [ 90, 30, 1 ],
“ProfileLookTableDims”: [ 36, 8, 16 ],
“ProfileHueSatMap1”: […

However if one loads that profile in RT the Tone curve is active and the checkmark turns it on and off. I don’t know where Tone data comes from or how it interacts with the profile. Anyone?

Iirc, if there is no Tone curve in dcp, RT adds Adobe Default Curve.

1 Like

Ok, so perhaps I was reading too much into the missing tone curve, thanks @heckflosse. Too bad though, that’s one of the reasons that make DcamProf profiles the benchmark.

It would be good to have better feedback regarding what tone curve, CCP, matrix etc is loaded. Might be a gui nightmare however.

This is why I’ll not be toiling to incorporate DCP profies in my software. I am wholly not interested in having my camera profiles do anything other than describe the data for the color transform, and with ICC profiles I can make sure the TRC does nothing, leaving only the primaries (or the toXYZ LUT) for the color transform. Later, I might work on OCIO for an ACES workflow, but right now it’s the GGB workflow for me… :stuck_out_tongue_closed_eyes:

Sorry to say, but I’m seeing a little bit of fud being spread (most certainly not intentionally) here. The way RT applies DCP profiles is very clear (*): there are check boxes for controlling exactly what is applied, and for dual-illumimant profiles you can also select which illuminant to use or whether to blend them according to the current wb temperature (*).
If you don’t want the embedded tone curve, untick the relevant box;
If you don’t want the LUT, but want to use the fwd matrix instead, just uncheck ‘apply base table’
If you don’t want the custom look table, uncheck the relevant box.
If you don’t want the baseline exposure, uncheck the relevant box.

(*) The only thing that’s not super clear imho is how the interpolation happens for dual-illumimant profiles. Intuitively, the two profiles are ‘blended’ according to the current wb temperature, but in fact the code in RT uses different ways of computing the temperature for wb and for DCP blending, which might result in some surprising behaviour for the careful user (e.g. if you have RT report a temp of 6500k but there are colour differences between selecting “interpolated” and “6500k” as DCP illuminant, most likely the wb temperature calculated by the DCP code is different from the one reported in the GUI).

2 Likes

That’s definitely a good way to handle it, but I still don’t like 'em… :smiley:

Well, I have no problem with that :wink:

1 Like

Thank you @heckflosse, @JackH and all the others for your explanations. It’s very interesting here!

Making my own dcp profiles with DcamProf, or to be honest with Lumariver Profile Designer as it’s easier for me to use :yum:, is a lot of fun. And therefore it’s useful to understand the converting process. One reason why I love RawTherapee is the possibility to use dcp profiles and being able to deactivate all the LUT’s and tone curves in there if I want to, just like Alberto said.

I would have a lot of more questions, but they all off topic here. So another time, maybe :slightly_smiling_face:

Folks, to stay on topic, start new threads. :wink:
Link back to this thread or one of its posts if you want.

@Erop Your first thread is so popular. You’re a rock star! :stuck_out_tongue:

From this discussion it seems that there are two types of values affected by the checkbox in the title: negative and greater than 1. Of these I would assume that the more problematic are negative ones, since those greater than one are probably dealt with by tools with ‘reconstruction’ or ‘protection’ in their name. Is this correct?

If so the main worry are negative values, which arise in the deep shadows and may or may not be relevant to the artist. Mostly not, one would assume, other than in heroic EC recoveries. So perhaps one suggestion could be to have a button next to the checkbox that displays what tones in the image are blocked when it is ticked (if clipped tones are also worrisome for later processing two colors could be displayed, one for blocked, one for clipped).

As an aside, do the clipped shadows/highlights buttons refer to the output color space as I always assumed?

At least some tools with reconstruction in their name are prevented from accessing clipped highlights if the box is ticked.

Tick the box. Loose ability to recover highlights.

The exeption is the tools in the exposure module itself.

That is why I requested that PhotoFlow have two boxes to separate the clipping. I always keep overflow clipping off and occasionally negative clipping.

image