A couple thoughts on this thread…
If a project is immediately applying the RRT to a file, it isn’t really doing the right thing. They should only be applying an IDT to get into linear light (and then possibly into ACEScc) for grading. The grade should be
applied before the RRT and so any contrast change (slope in log, or power in linear) should change the scene light in a consistent way that is independent of the RRT. Applying an ACES Viewing Transform (RRT/ODT) should be able to be turned on or off without affecting the data.
Of course, what you see on the monitor might be a different thing. The biggest apparent effect from the RRT is the roll-off in the highlights and shadows that in the RRT are chosen for a 0.005 to 10,000 nits display (so it is HDR ready). If you just looked at the RRT, there sometimes is a better image though with a lot of clipping.
The ODTs have a big effect on the look shown on SDR displays. I think it would be a nice feature I think if an
HDR ODT could be used appropriately on an SDR display. This would let you see lighting ratios correctly at the expense of not seeing what the final image would look like exactly.
There is a problem in applying the RRT in the Red direction because of how intense the Reds get. The feedback was to try and control that (as part of the process Doug mentioned). So some of the changes in the RRT are not necessarily an optional ‘Look’ as described in the paper, but rather trying to patch objectionable parts of the rendering so that to first glance, the image appears in the ballpark. We had DPs
say that without some of the things that were done, “they might be fired” if they showed that image. That alarmed us and therefore the correction may have been too far. Sometimes one fix then led to another to compensate. If you have a good sense of the needed target for everyone, a cleaner implementation would really help. I predict this will get looked at for sure.
Early in the development of the RRT, the tone curve ACES used was very similar to Vision 3 print-through curves and changes were done to lower that contrast and clean the roll-offs some, but it still has an overall s-shape that resembles Vision 3. The design choices were targeted at Cinema with adjustments for HDR/SDR.
The prevalence of different output targets ( HLG/PQ/Game Engines/VR ) is highlighting that the RRT/ODT viewing transforms have some limits that need to be thought about… Timing of contrast should still be completely under the control of the user and where that doesn’t happen it should be fixed. Even in the current system, you can make ODTS that don’t have the rolloffs, then there would be obvious clipping in the image that would have to be timed out, and you are back into an arena where each grade has to be unique for each display device. The main justification for the ODT system was to allow changes in the reproduction for each device so that any contrast changes due to viewing conditions could be dealt with and the same creative grade could still be used. The ACES Viewing Transforms are a do-your-best on each device with different viewing conditions. The dim vs. dark surround issue is really important in ACES to get the right results.
I see in the thread a ‘crossed-streams’ about the ‘Look’ of the RRT - sometimes there is discussion of the Red ‘extras’ as being the look that needs to be moved, and sometimes there is discussion of the 1.5 gamma present in the RRT being removed to get it to be neutral (i.e. if you take an AcesCC image with no viewing transform and apply a slope of about 1.5, middle luminances will be about the same)
Putting in greater or lower contrast, and systematically enhancing certain colors has always been part of the LMT approach. Regretfully, the tools for making these are not often in the hands of the users. (There is a LoCon LMT in the ACES distribution, but it is often not apparent in user interfaces or even included in a vendor distribution). Yet another thing that needs more work.
Since AcesNext is in a gathering feedback phase, this is a good discussion to have.