Wow, there are a bit more posts I’ve expected 
@Erop Welcome to the forum!
Thank you afre
And thanks to all of you for the answers! Now I do understand what this mysterious checkbox is for. And indeed, renaming the box would make sense.
1 Like
I’m such an end user, but in my opinion “gamut” is not a good term in this case.
As far as I understand, this box affects “overexposed” areas only. But you also can be out of gamut with oversaturated colours. Actually the latter is what I am thinking of, when I hear about out of gamut colours. That’s why I assumed, that this check box has something to do with rendering intents, which obviously is not the case.
In this raw conversion context, I assume that by RGB you mean raw space, say values from a pixel quartet. If so raw tone [1, 0.985, 0.001] in RGB could map to something like [2.505, 1.2230, -0.3934] in linear sRGB, with a Z7 around D55 for instance ([1.445 1.395 -0.150] in XYZ). These values being outside of the 0->1 parallelopiped indeed guarantees the tone to be out of gamut in sRGB.
So with gamut at its simplest, we agree. Or are you being more sophisticated than that? Is RT more sophisticated than that?
1 Like
Not quite, you are thinking Lab I am thinking linear RGB. So far I have tried to keep my contribution simple, and the parallelopipeds approximation for gamut achieve that in a raw conversion context, albeit at the expense of nuance. They are easy to visualize and make it intuitive to understand that if a tone falls outside of the relative one for the output color space, it is necessarily out of its gamut. Change the output color space, change the calculus.
In the linear sRGB example above there are a number of options on how to squeeze that tone into the relative raw-converted file, all suboptimal non-linear compromises. At its simplest we could for instance simply clip R and G to 1 and block B to zero. Or we could get more sophisticated than that. I am not a programmer and did not read the code but my understanding is that the checkbox determines what option is kept open early on in the conversion path.
The additional nuance comes from taking into consideration the range of ‘visible’ colors. This complicates the discussion exponentially and imho would not add much to it in this context - unless RT does take it into account, which I did not think it did (does it?). There is a reason why bringing up rendering intents in a forum for color scientists usually ends with someone taking the ball and going home - and why to this day most of them are fudged or inscrutably broken.
1 Like
No, it doesn’t.
1 Like
And Rawtherapee does something more sophisticated than a simply hard clip
2 Likes
Thanks for that review, it makes sense and clarifies the terminology used here (not so sure about those vertical beams though;-)
Indeed, I thought that was the point of this thread on the referenced checkbox.
Not quite, you are thinking Lab I am thinking linear RGB. So far I have tried to keep my contribution simple, and the parallelopipeds approximation for gamut achieve that in a raw conversion context, albeit at the expense of nuance. They are easy to visualize and make it intuitive to understand that if a tone falls outside of the relative one for the output color space, it is necessarily out of its gamut. Change the output color space, change the calculus.
In the linear sRGB example above there are a number of options on how to squeeze that tone into the relative raw-converted file, all suboptimal non-linear compromises. At its simplest we could for instance simply clip R and G to 1 and block B to zero. Or we could get more sophisticated than that. I am not a programmer and did not read the code but my understanding is that the checkbox determines what option is kept open early on in the conversion path.
Thank you Jack for your explanation. Some of the points mentioned are difficult for me to understand, as I’m not a colour scientist, but just a hobby photographer interested in colour management. However, I think I got the point. It is not necessary that all 3 channels (R, G, and B) get a value higher than 1 at once, to become influenced by the check box. Even a colour which consists of the components R=1.2 G=0.8 B=0.5, in a certain working colour space, would be clipped to R=1.0 G=0.8 B=0.5 if the check box is activated.
By the way, do I assume correctly that the raw RGB values from the AD-converter first are multiplied by a certain value (for example Rx1.4, Gx1, Bx1.8) to get the white balance and then are multiplied with the Forward Matrix of the DCP-Profile to get XYZ values? At last, if no LUTs are applied by the DCP-Profile, the XYZ values become transformed into the RGB values of the working colour space. Am I right?
Basically you are right. The order of the steps might be different (for example applying a forward matrix before the white balance) and also RT does not ship a DCP for each camera.
For raw preprocessing and demosaic also a (camera or automatic) white balance is applied before this steps and reverted after this steps to apply user defined white balance afterwards to get better results by using auto or camera white balance for the (pre)demosaic steps. Not so easy to explain all this steps…
1 Like
Not sure how I did either, however thanks.
One problem is that the RTv4 profiles have a gamut of 1·8 (or at least the Large profile does) and a gamut of 1·0 is needed to get the best results with a floating point workflow.
Hint: create your custom profile using the tool with the + sign.
1 Like
Elle Stone has a collection of really nice profiles here:
She has a set of ProPhoto profiles with various gamut:
LargeRGB-elle-V2-g10.icc LargeRGB-elle-V4-g10.icc
LargeRGB-elle-V2-g18.icc LargeRGB-elle-V4-g18.icc
LargeRGB-elle-V2-g22.icc LargeRGB-elle-V4-g22.icc
LargeRGB-elle-V2-labl.icc LargeRGB-elle-V4-labl.icc
LargeRGB-elle-V2-rec709.icc LargeRGB-elle-V4-rec709.icc
LargeRGB-elle-V2-srgbtrc.icc LargeRGB-elle-V4-srgbtrc.icc
Not sure what you mean by best here, but the ‘gamma’ (non linear TRC) of 1.8 is perfectly according to the specification: ROMM RGB
Internally, RawTherpaee (mostly) works in linear RGB.
When I output the file as an integer tiff and import it into Photoshop then no problem. When I output the file as a floating point tiff and import it into Photoshop then it is way too light. If I do the same with the v2 profiles I get the same issue. However, with v2 I also have a version of ProPhoto with a gamma of 1.0 (and an sRGB gamma 1.0 profile) and the floating point tiff gives the same reproduction as the integer tiff when I use that one. (I have checked that the RT iccs are copies into the folder for the system colour profiles so it is not a case of Photoshop not having access to the profile).
I get the same results when using the Elle Stone profiles that @ggbuthcer referred me to. If I use the Large with gamma 1.0 then I get the same picture whether using integer or floating tiffs. If I use the gamma 1.8 version then only the integer tiff version gives me the same picture as I exported (and similar to the gamma 1.0 version apart from the expected differences in the shadows).
Thanks for that link.
1 Like
We’re veering off topic here, but this sounds like an issue with either the floating point TIFF export from RawTherapee, or Photoshops capabilities to read it. Maybe you could file a bug report for that so we can investigate what is going on? Issues · Beep6581/RawTherapee · GitHub
Thanks. Bug report submitted as Floating Point Exports have the wrong gamma · Issue #5893 · Beep6581/RawTherapee · GitHub with files at Filebin | e0ld7kd1c4ascl41 it may be a Photoshop problem as my version is a bit old, but if other people can reproduce it then it needs dealing with.
You are welcome… and likewise 
As @heckflosse mentioned that’s pretty well the desired end result though how one gets there depends on convenience. And, depending on the dcp, getting there may require LUTs, see below.
Ideally linearly and with no other edits, yes. However, around the time they stopped using Process 2012, Adobe dcp’s Forward Matrices began to be desaturated, only to then be re-saturated by subsequent LUTs, what I believe RT calls ‘Base’ and ‘Look’ tables. I think this was done to ensure that all raw tones make it into XYZ unscathed by the color transformation, in order to then squeeze them into the final look (Standard, Landscape, Portrait etc.) in a controlled fashion, thereby minimizing out-of-gamut values where possible. By definition this causes tones to become processed non-linearly from the very earliest stages of conversion.
Until recently Adobe’s dcp’s also included a ‘Tone curve’, which looked very much like the default ‘Film-like’ curve in RT. Its job was to increase contrast to make images look better when displayed in the typically smaller contrast ratio of our monitors (if you are using a dcp with the Tone curve enabled make sure to reset the ‘Film-like’ panel, otherwise you are effectively applying it twice). The only issue with this approach was that introducing a tone curve so late in the color transformation caused chromaticity shifts. Suboptimal, but most of us did not mind given the fact that that’s the way it had pretty well been done in typical raw converters from the beginning of digital.
Then a couple of years ago, when they reworked Profiles in ACR/LR and introduced Process Version 5, the Tone curve disappeared from Standard dcp’s. ̶ ̶T̶h̶e̶ ̶F̶i̶n̶a̶l̶ ̶i̶m̶a̶g̶e̶s̶ ̶l̶o̶o̶k̶ ̶a̶b̶o̶u̶t̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶ ̶t̶h̶o̶u̶g̶h̶,̶ ̶s̶o̶ ̶m̶y̶ ̶g̶u̶e̶s̶s̶ ̶i̶s̶ ̶t̶h̶a̶t̶ ̶t̶h̶e̶y̶ ̶i̶n̶c̶o̶r̶p̶o̶r̶a̶t̶e̶d̶ ̶i̶t̶ ̶i̶n̶t̶o̶ ̶t̶h̶e̶ ̶’̶L̶o̶o̶k̶’̶ ̶t̶a̶b̶l̶e̶,̶ ̶w̶h̶e̶r̶e̶ ̶i̶t̶ ̶c̶o̶u̶l̶d̶ ̶b̶e̶ ̶a̶p̶p̶l̶i̶e̶d̶ ̶t̶o̶ ̶t̶h̶e̶ ̶L̶ ̶c̶h̶a̶n̶n̶e̶l̶ ̶o̶n̶l̶y̶ ̶(̶V̶ ̶r̶e̶a̶l̶l̶y̶,̶ ̶L̶U̶T̶s̶ ̶i̶n̶ ̶d̶c̶p̶ ̶w̶o̶r̶k̶ ̶i̶n̶ ̶H̶S̶V̶ ̶s̶p̶a̶c̶e̶)̶ ̶t̶h̶e̶r̶e̶b̶y̶ ̶r̶e̶d̶u̶c̶i̶n̶g̶ ̶c̶h̶r̶o̶m̶a̶t̶i̶c̶i̶t̶y̶ ̶s̶h̶i̶f̶t̶s̶.̶ (Apparently just a default, see further down).
All this to say that with a modern Adobe dcp (or DcamProf at default for that matter), ‘no LUTs are applied’ does not apply.
Jack
2 Likes
How sure are you about this?
I have the impression that (at least in RT), when you only select ‘Base table’ in the DCP there is only a matrix conversion taking place, not LUT at all. see Alberto’s response below
The base table is a LUT