Nah. That’s the expected result under OpenDRT sRGB target for Red Christmas. Add the gamut compression operator from Jed’s github which is available either as .nk or as DCTL if you want it to look correct. Once you have that, you can finish fixing it by adding some extra grading nodes.
Optionally, the gamut footprint should have no impact on tonality in the broad stroke sense.
I do get a different result than your image but maybe you’ve used different settings.
If you want to verify differences within the OpenDRT probably better to just download Resolve yourself. It’s free 
(your jpg from Nuke - right // resolve OpenDRT v82 dctl right)
Default surround in the version without _params is average for sRGB display. I have yet to try new 0.82 with ICtCp perceptual dechroma but that might fix one of the issues I had with 0.81. I’m going to do some more tests tonight and integrate it in BG3 engine if it does.
I think I’m seeing something reddish… has anyone else noticed that OpenDRT renders whites more reddish? If the whites aren’t perfectly neutral they seem to get this tinge of red, so much so that I wondered if the whitepoint might be wrong, but it probably isn’t. Same images through RRT+ODT, and for example ALF-2, have whites that look “neutral” in comparison. I’m specifically talking about whites like the white patch in the colorchecker. Example images like the ARRI/CML images with colorchecker in them in various dropboxes, and even the one from RED in the beginning of this thread to some extent show it. Overall to my eye the images come out of OpenDRT more red.
((Off topic)) Is OpenDRT being used in BG3 or are is it just RnD? Would be quite cool. Look forward to the game. Good luck with development
This is interesting. Do you have a more specific example?
Based on my testing, I’m pretty confident that equal-energy input chromaticities will be equal energy output chromaticities (assuming input whitepoint == output whitepoint), but maybe I’ve missed something.
Certainly the overall look is a bit different because the render transform is not per-channel like most camera vendor display rendering transforms. For example, less desaturation in brighter parts of the image, etc. Here’s a quick comparison using one of the CML test images:
OpenDRT: Rec.1886 default preset
ARRI Classic 709
ACES Rec.709
I’m just starting to look at OpenDRT and I’m starting with skin tones and I think the redness of OpenDRT shows up especially well with skin tones, but also with warm light; more reddish than orangish. I think the RED image shows it well as well in this thread.
Here’s three renderings, ALF-2, OpenDRT with ALF-2 tone curve and OpenDRT.
ALF-2:
OpenDRT with ALF-2 tone curve (extrapolated for ACEScct range):
OpenDRT:
WIth the ARRI’s Isabella image to my eye I’m seeing the whites also more reddish, which prompted the question. It was noticeable enough so that I ended adjusting the whitepoint. Same set of renderings follow (not adjusted):
ALF-2:
OpenDRT with ALF-2 tone curve (extrapolated for ACEScct range):
OpenDRT:
ACES 1.2 with ALF-2 tone curve:
Obviously these images aren’t balanced but it’s interesting to see the warmer rendering of OpenDRT. At least I’m seeing it with my eyes/display.
EDIT: For completeness I added also ACES 1.2 with ALF-2 tone curve rendering ffor comparison.
2 Likes
Definitely correct as the skin chromaticities are making it out of the display under Jed’s efforts, while per channel will skew to a digital yellow-ish, and will accidentally dechroma in a rapid fashion. Very noticeable where camera sensors get near maximum.
1 Like
It looks indeed very correct and usable in these normal life images.
I do see a nice warmth in skin tones, but I don’t think it’s due to any sort of skew of red but simply that OpenDRT is doing a nice job of getting the hues in the image to come through. I believe the hues are quite accurate, and that possibly the reason this can be weird is that we are used to output transforms that do skew colors as Troy was saying.
What I am seeing in OpenDRT with skin tones is that people’s skin tend to look a bit flat and pastel, like the way a person looks in real life when they have lots of foundation make-up on so their skin’s natural translucency and pigment does not come through. I believe this is because of the tonemap which is quite neutral currently, looking almost “log-ish” in the sense that it is very low contrast.
Would it be appropriate to discuss the tonemap of OpenDRT at this stage of development?
I know that in the ACES retrospective it was said that the current ACES tonemap was too aggressive and thus imposed too much of a “look” on things. I totally agree. However, it said there that the goal was to make it “slightly” less strong. The current tonemap feels especially neutral, almost like there is no tonemapping.
From the point of view of lookdev, I would personally prefer something more like the tonemap of SPI-VFX or SPI-ANIM which was less agressive than ACES, but did give a filmic look. I can of course grade the current OpenDRT tonemap in comp to go from this (which looks kind of pasty-morgue like):
to this, which makes the skin look a lot better, more vibrant:
The thing is, I’m not really doing tonemapping at all, I’m doing gamma gain. I’d much rather actually use tonemapping, which I would get from the output transform in my render view. I would wish that that default output transform was not as neutral as it is currently, and had more shoulder and toe… just not as aggressive as the current ACES.
Similar to the endless yellow fire discussions, I would consider this topic to fall more in the realm of “look transform” than “display rendering transform”. I agree that the tonemap as I’ve set it up is quite low contrast, but I believe that this is appropriate for the design goals.
I also agree there should be more contrast in its “default look” state, which does not currently exist yet…
1 Like
Understood, thanks Jed!
The issue with the whites appearing reddish seems to be because the red just stays much more saturated. The skin appearing pinkish seems to be because the red not only gets lighter it also stays more saturated, in comparison to the two other DRTs. Here’s more extreme example with the skin tone:
ALF-2:
ACES 1.2 with ALF-2 tone curve:
OpenDRT with ALF-2 tone curve:
OpenDRT:
And here’s same with exposure -6 to look at the white tablecloth (lit with HMI):
ALF-2:
ACES 1.2 with ALF-2 tone curve:
OpenDRT with ALF-2 tone curve:
OpenDRT:
And synthetic chart ACES reference image:
ALF-2:
ACES 1.2:
OpenDRT:
I don’t really want to get into look discussion at this point either with OpenDRT, but I’m not sure whether this “tinge of red” issue is a look issue or DRT issue? Since there’s dechroma happening in OpenDRT, maybe it can do something more to improve this.
That’s funny as the fact that it has less contrast by default made it universally liked by the cinematic and lighting team at Larian and there’s the _Params version for those who want more contrast.
Is the Isabella image (in raw) available from a public website?
1 Like
Yeah it’s an interesting question I think. A couple of observations:
The behavior of the ALF-2 rendering is a bit different. It has much stronger “highlight desaturation”, and more saturated midtones and shadows. Hues are compressed towards the secondary colors (CMY) with increasing input luminance, and expanded away from the secondary colors with decreasing input luminance. (We probably don’t see much of these hue effects with a chromaticity so close to achromatic like the tablecloth in your above example). These features are byproducts of it being a per-channel display transform.
OpenDRT preserves more saturation in highlights, and is much more chromaticity-linear across the range of input luminance. This does cause the tablecloth in the above example to look more reddish, because the input chromaticities are being preserved more faithfully.
I am not disagreeing with you that the ALF-2 transform looks better in this case, but that is not the question. The question is which behavior is preferable for the design goal of a neutral faithful “no look” rendering of the input chromaticities?
You could certainly argue that there should be more “highlight chroma compression” in OpenDRT. For example in @Derek’s tests he was boosting dechroma and saturation a bit. This mimics the behavior of the per-channel rendering, which has stronger “highlight desaturation” and stronger “midtone saturation”.
If we do this adjustment in the DRT, what happens when we don’t want this effect in a look applied upstream though? Our hands are tied. This is why I have chosen the settings I did, to keep as many options open as possible for look creation.
Certainly though, I do agree that a stronger “highlight desaturation”, and a stronger “midtone saturation” might be desired in most cases, aesthetically. This is something that can absolutely be engineered as part of a look transform.
Hopefully my reasoning makes sense, and if anyone disagrees I would be happy to hear why!
This is the perfect example of what I’m talking about… Different domains (video games, feature film, episodics, feature animation) and even different projects (horror movie, romantic comedy, fantasy, super hero movie, sit-com) all have different creative requirements, which might require different looks, or even completely different DRTs. Flexibility should be a goal. This is the reality we live in and to not acknowledge this and incorporate it into our design decisions is shortsighted.
1 Like
Well, the reason why the art teams liked the lack of contrast of OpenDRT is not about look but about being able to bring back contrast on their own term instead of having it pre-baked in. Those who were accustomed to game tonemapping hated it on first sight until we explained proper grading workflow to them 
. In that sense, I would reduce baked-in look even more. I didn’t submit with in Larian’s codebase with SDR saturation at 1.0 but, personally, I think that’s an even better starting point than saturation at 1.2.
Edit: Btw, I use game tonemapping as a portmanteau for TMO that have a very finished look like the Hable-Hejl-Burgess tonemapping operator and can thus be used by video games without applying any colour grading. ACES 1.0 with the RRT (and 1.2 with the RRT sweeteners) would fall into that category too although there were complaints that it looked too dark and too orange. We did ship Divinity Original Sin: II with ACES 1.2 and SDR on SSTS + blue correction + extra exposure compensation and white balancing everything towards blue so it can work.
3 Likes
Sure does! Marvel’s Spiderman on PS4 is ACES and was/is gorgeous!