Why RRT/ODT sRGB makes the look darker?

Discussions - Using ACES
1

Hello,
I’m using ACES with a sRGB monitor and I wonder why the look of a linear input to the RRT/ODT sRGB looks darker than what other tonemap tools would to? (keeping the same midtone value but only make the highlights softer)
I don’t have any problem with that since increasing the exposure can compensate it but I wonder why this choice was made? is there a technical reason to that? is that the same with all the ODT’s?

2 Likes
2

Hi @Vincent_Gires,

This is a good question and here are a few answers:

  • The ACES RRT was designed for Theatrical Exhibition where Viewing Conditions are Dark. Content for cinema tends to be authored with more contrast to compensate for the dark surround.
  • Even though there is a surround compensation process (Dark <–> Dim), the values to drive that process were subjectively obtained and it might not be enough for all the cases.
  • The RRT + ODTs are also the results of viewing images by an expert viewer, so there undeniably some subjectivity built-in.
  • Your current Viewing Conditions might not be that expected by the ODT you are using, are you under Dim ones?
  • Some companies such as Epic Games are pre-exposing the Scene-Referred Values with a 1.45 gain.
  • We touch a lot of that in the ACES RAE paper: ACES Retrospective and Enhancements

Hope this helps! :slight_smile:

Cheers,

Thomas

5 Likes
3

Thank you for your answers.

Actually, this does not make a big difference to me. In any situation (viewing in dark or bright environment), viewing linear data with the sRGB ODT looks always too dark unless I increase exposure.

4

Yeah so this is unfortunately in the subjective realm, for the many people that find the RRT too aggressive you will find an equal amount either not minding it or loving it. In any cases, we advocated for a more neutral look in the RAE paper.

5

Maybe it’s not the right topic to talk about that but I wonder then if the RRT look is optional, it means that if EXR files are sent to another studio, how to be sure that the chosen look is respected? right now this is quite easy: one exchange colorspace and the RRT is integrate in the target ODT. No way to make errors (at least, it should).

In the opposite, you have the Filmic tonemap in Blender which is very neutral by default but the contrast is set in a OCIO look, which is great, but if I send my EXR to someone, it can be seen from low to high contrast, which change completely the way of a scene can be lit/grade.

6

There’s a misconception about the “look” word here, but it’s been since the inception of ACES: there shouldn’t be any artistic intent in the default tone mapping, but that is something almost impossible. What was wrong was to originally go for something with a rather strong intention, instead of going for a “default” LMT separated from the RRT, with potentially a RRT that would have looked terrible, but at least it would have told the world that ACES doesn’t have “one” look! It would also have left the disabling of said look in the RRT easier, instead of having to use complex invert functions. It was too much based on old DI workflows, where one LUT would make the show look, and probably too much hassle to implement in softwares. But let’s talk about the future, having a proper Look/Render/Output is the way to go, and there will be a lot of debate on how to /whether we have to match the different outputs :slight_smile:

2 Likes