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
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… 
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… 