Here is the link to the spreadsheet that was shared during today’s meeting, showing a “living list” of requirements:
For now, the link is read-only, but all should be able to comment. (If anyone needs edit access, just contact me and I’ll be happy to add you.)
However, requirements-to-be-added that require discussion and are likely to spur extensive back-and-forth are probably best discussed here.
Suggestions that were made today during the call were:
As discussed in the last meeting, there is now a Google Form for putting in your own takes on the “T-Shirt size” task weighting for each of the requiments in the spreadsheet.
If you have the time, please take a moment and enter your subjective sense of the difficulty of each requirements, against each of the 3 current pathways. A minimally modied SSTS, Jed’s OpenDRT, and some sort of new CAM based DRT (ZCAMishDRT is a starting point only)
“No” being impossible.
S, M, L, XXL being how a big a task you think it is. (Assuming it is possible)
Thanks Alex and everyone for the hard work. I had a look at the last meeting and at the Google Form and I had a few commnents.
First, what are we comparing ?
Is it correct to assume that the SSTS (Single-Stage Tone Scale) is actually only one module of the ACES Output Transform ? And therefore what we are really comparing should be :
Sorry for the nitpicking… But I thought it was worth mentioning to avoid any ambiguity. I guess at some point the SSTS mechanism (a s-curve made of beziers) could be used in OpenDRT or ZCAMishDRT, and vice-versa ?
Because, and I am happy to be corrected, if we talk about a simplified version of the SSTS where we would put the “sweeteners” in a LMT, these “sweeteners” are actually part of the ACES RRT and not the SSTS itself ? For the record, I am referring to the “red modifier”, “glow module” and “global desaturation”.
So maybe, my question is : what are you exactly referring as SSTS ? Because it looks to me that we are really trying to evaluate here are the limits of per-channel (RGB) lookup used in the ACES Output Transforms ? Sorry if I misunderstood !
And maybe I can give my tuppence. Although I have been pushing for a “chromaticity-linear” approach since day one, I understand that there is a deadline to achieve and that we may have to come up with a plan in January. It looks like this deadline will be key in our choice for the next ACES Output Transforms.
And to play devil´s advocate, a very popular rendering solution called K1S1 is using per-channel (RGB) lookup. So it might not be the “ultimate” rendering transform I was hoping for but revisiting this approach, exactly like Jed did back in May, might be sufficient for the ACES 2.0 requirements. It really depends on how high we set the bar… But from the early tests I did, this experiment was “solving” some of the know issues of the current transforms.
An other comment I had is how close OpenDRT and TCAM are in their rendering. I already mentioned it once on slack and I will just mention it here once more. Investigating other rendering transforms to understand their mechanics like Jed did is excellent. This is tremendous work on his end to gather these experiments and knowledge in Nuke. But is there a line that should not be crossed ? One thing is to get inspired, another is to release an “open-source copy” into OCIO/CTL/GLSL… and every major software. To me, it would also be a missed opportunity for more diversity.
Finally, I wanted to mention JzDT. Could it be a potential candidate ? It looks like a rather elegant and simple solution. Again, I guess it all depends on our constraints of time and quality. Would it be the “ultimate” rendering ? Probably not. But does it matter ? I don´t think so for two main reasons :
And that would be my final comment. In the last TAC meeting, Rod Bogart mentioned an interesting solution because of the schedule. This is how I understood it :
Sorry for the long post… I hope it helps a bit !
Chris
Yes. SSTS is only one module of the “ACES Output Transform” approach (e.g. the HDR transforms introduced in ACES 1.1). A minimal change version could include moving or removing the “sweeteners”, tweaked parameters for the SSTS (tone scale), and cleaned up logic in the display encoding steps. But fundamentally, a “minimal change” would still be a per-channel lookup. Therefore, for the “hue-preservation” requirement - the ACES OT/SSTS approach would get a “no” in the difficulty rankings (or maybe an XXL if more severe changes were to be permitted).
Thanks Scott for your answer ! That is much appreciated.
I have tried to fill the form to the best of my abilities but unfortunately I did not get a chance to evaluate ZCAMishDRT properly.
Regards,
Chris
Dropping this one here as a future Output Transform: DCI HDR Image Testing Video - YouTube
DCI next-generation Theatrical HDR black and white levels will be along those lines: [0.005, 300]nits.
If I understand correctly, this is for cinema dark surround and should be graded so the 300 nits peak leave the impression of seeing the same image as on the Netflix version with 1000 nits peak viewed in dim to average surround no? For the record, I agree that 1000 nits in a very dark surround is eye-searing and 300 nits with a wider gamut is a huge improvement over current cinema 48 nits 
Yes, this is for Theatrical Exhibition. I would need to dig a bit on our Slack archives, but we found some research a few years ago that was saying that 600nits was the maximum peak luminance under sark surrounds after which viewers were experiencing discomfort. I will check later!