Not sure I get the connection there @ChrisBrejon - though obviously where mid gray ends up is definitely important 
Well, midgray pegs at 0.10 at displat linear mostly because of dark theaters, right ? If streaming and Netflix become the norm (because of covid for instance), is there a case where tv sets, smartphones and ipads would benefit of pegging midgray at 0.18 in display linear ?
Joshua’s answer on this matter is brilliant.
Chris
I think these discussions are solidifying (at least in my mind) the need for multiple styles/variants of output transforms. I would hope that an acceptable outcome of this VWG is the decision (if made) that we can’t hit all the targets with one group of OTs, and to provide all the necessary OTs as required.
For HDR I am seeing two distinct variants needed:
-An HDR transform that creates an image that reasonably coincides with the SDR transform. There have been stated numerous and valid reasons why this workflow is necessary. This would be created after (or possibly alongside) work on a new SDR transform is done.
-Because that transform will almost certainly make compromises and restrict what could be an “optimized” HDR image, we need another OT that is less restrictive for HDR for those that need/want it.
-There are also some specialized transforms that @sdyer has mentioned, like SDR within an HDR container that is good for comparison work.
It is feasible that an LMT could accomplish the first goal, but I really dislike the idea of a “default” LMT having to be applied; that feels too fragile in my mind. We probably need to start a separate thread about a default LMT if that continues to be a possibility, and/or flag that over to the architecture group.
Previous ACES RRT styles are available via a LMT, why the first goal would be any different than those, especially when it is also about emulating a look.
Assuming for a second, that we are going down the road of adding a different rendering transform that makes HDR look like SDR, what do we do then about the existing emulation LMTs?
If we don’t do anything, we are left with a dirty system with transforms doing similar things but categorised differently and if we move all those LMTs as new Rendering Transforms, we end up with an explosion of RT and the role of the LMT becomes muddy.
This is certainly not a great situation from an architectural standpoint.
Cheers,
Thomas
That’s a valid point; at the end of the day it’s about simulating our SDR look.
However, what I think differentiates this circumstance is that it might reasonably be the default/base look that is widely used, unlike the LMT’s provided for backwards compatibility/comparison. One of the discussions a couple meetings ago was how a fair number of people use ACES simply because “it works”; the necessity of using a default LMT to get a base look, but only when doing HDR, convolutes the workflow.
These will all have to be re-developed for ACES 2.0 anyway since we are changing the OT (including rendering), do they not?
The inverse is also true, though, that SDR would look like HDR. So in the case of a production doing an HDR master first, the SDR grade should be a simple trim pass (and possibly not even needed in some circumstances). If the “standard” HDR OT looks wildly different from the SDR OT, best case scenario there is an LMT that gets it close and do final tweaks from there, but worst case you’re doing a full grade again in SDR.
Just throwing it out there, but maybe this is better as a both/and approach. There are two HDR transforms available: one that “matches” the SDR OT and one that is less restrictive. There is ALSO an LMT available that can be used with the less restrictive HDR OT to match the SDR look. This would be comparable to say rendering directly in 0.1.1 versus using an LMT and rendering in the current version. Both should yield the same (or very similar) results, but either can be used depending on workflow.
They are provided for compatiblity reasons but with the intent of simulating a particular look, and instead having 3 or 4 RRTs, the choice was made to have a single one and use the dedicated tool in the block diagram to handle look changes. Unless it is impossible to preserve the SDR look in HDR via a LMT which it might be although I don’t see why, I don’t see a really compelling reason to break the entire system for that.
You have n “Old” LMTs mapping to RRT 1.0, you only require a new one mapping from RRT 1.0 to RRT 2.0 to be able to use the n “Old” with RRT 2.0.
The thing to consider (and that people wanting different RT seem to miss), is the combinational explosion for CMS with fixed configuration, e.g. OCIO.
To put things in perspective, the current ACES 1.2 Config has roughly 25 OTs for users to chose from, should we have two styles, e.g. current vs hue-preserving, we would double the count, i.e. ~50 OTs. If we wanted the SDR look maintained for HDR, we would go from 8 to 16 OTs to perform the job of what a single LMT might be able to do.
To be clear, I’m not against having multiple RT/RRT, I’m just extremely careful about the consequences of doing so because I also happen to be at the other end of the barrel. We have great powers but also great responsibilities.
Cheers,
Thomas
That’s good info, thanks @Thomas_Mansencal. I don’t do much with OCIO (although I believe a lot of people do), so that’s good consideration.
Totally off topic, but I was just having a brief look at OCIO in AE and at the OCIO website and it appears user-selectable parameters beyond input and output space would not be possible (for the end user), is that correct? The concept of user-selectable parameters for OT(s) in ACES has been brought up a couple times, but it looks like that couldn’t be reproduced in OCIO… which is unfortunate as you could severely decrease the number of separate configs if you could say, choose the white point (D50, D55, D65, etc) in OCIO and have it call the correct transform in the chain, instead of having to maintain discreet libraries for every option.
The config itself is fixed but it is possible to change dynamically parameters on various transforms such as the CDL Transform. ACES, on the other hand, has no dynamic parameterisation, you can swap a transform for another but the transforms themselves are fixed. You cannot really change how they behave and there is no immediate plan to handle dynamic parameterisation as it opens a great metadata pandora box nobody dared to look inside yet! 
It certainly does not mean it is not something that was talked about or has not been considered, it is just really hard to do right.
Cheers,
Thomas
There’s one thing I believe we should all consider which is the “in my humble opinion” obsolescence of the 100nit SDR standard. No consumer TV (or GUI monitors) is 100nit when in SDR (200 to 350nit seem a good average) out of the box. I have several clients (Broadcast mostly producing in HLG) saying that they are calibrating for 203nit to have a similar feel to their HDR, but that they are struggling with greyscale tracking by those displays. I guess, what I’m trying to say here is that maybe a revision by SMPTE, ITU, etc… of the SDR standard to accommodate a higher peak luminance would be much needed so we are not chasing our tails too much when the artistic intent need to be preserved in both SDR and HDR in simultaneous production (or… on a film set! where both technologies will co-exist for quite some time).
I would also consider the same standard of 5 nits dim ambient light for both SDR and HDR content production should be reconsidered.
I know none of this is the tasks of the OT working group or ACES, but maybe raising our voices to those standardization bodies might help the work we’re trying to achieve here?.
4 Likes
100% agree. The fact that HLG settled on 203 nit for diffuse white and PQ quickly updated from 100 nit to 203 nit makes me hopeful there wouldn’t be too much pushback on allowing at least an “alternate” recommendation or standard for SDR.
1 Like
Scenarios 2 and 3 are what I would prefer from a User’s perspective.
If there are suitable “existing solutions” I would suggest using these as foundations to improve upon.