my name is Daniel Brylka from Hamburg, Germany. (www.toodee.de)
I am woking mostly with Autodesk Flame and The Foundry´s Nuke.
We are setting up a test project in ACES with Resolve, Maya, Nuke, Flame and Affinity Photo and we are using ACES 1.0.1 at the moment.
A question was coming up how to deal with subtitles in an ACES feature pipeline.
The same applies to supers and colored logos in commercials I guess.
A white title in RGB 8-Bit is 255/255/255, this is 1.0 in ACES and of course not “white” anymore. I don’t want to use max. values in ACES of 16.292 due to possible antialias edges artifacts.
On Flame I would first “burn” in the ODT and then apply titles and logos in Rec.709 for HD, but I wonder how the workflow is on an ACES feature production with subtitles for a Rec.709 and a DCI-P3 output for example.
The same problem I am running into when using a known sRGB Logo-color of a company XY, loading this into Nuke with the ColorSpace Utilities/sRGB/Texture and ending up with a reduced saturation in ACEScg.
have you seen the 1.0.3 OCIO setup? It’s not final and switching to it already messed up one Nuke (10.4) script for me (colours got flat and error messages on a few nodes about peaking values). So proceed with caution and backups. The reason I tried it out was similar to yours, compatibility to regular sRGB content. I’ll wait till it’s official on my end. Right now I eyeballed a few transforms together to get my output to look right.
@Thomas_Mansencal oh wow, thanks I totally missed that, and I just checked yesterday. Will give it a shot again tomorrow and see whether that was a Nuke 10.4 fluke or if it happens again.
@frankjonen: As Thomas said, the 1.0.3 config has been officially accepted into the main OCIO repo. In my experience, Nuke is very finicky when it comes to switching OCIO config. Often, all of the OCIO Colorspace nodes’ in and out values end up getting reset to the working space colorspace. If you change the script’s OCIO config path in a text editor before opening in Nuke, you’ll probably have better luck with the script’s behavior remaining as you had configured it.
To the original question, the Output Transforms like ‘Output/Output - sRGB’ can be used to bring sRGB material into ACEScg. This is likely to give you a closer match than the Utility - sRGB - Texture space.
Hi @frankjonen, hello @hpduiker,
thanks for your reply. Yes, we know about ACES 1.0.3 and testing it. We want to use ACES 1.0.1 for the first project, because we have in all tools that we use as a standard anyways.
There we can even use in Maya and Nuke and Flame the Rec.709 RRT and get the same image results, knowing that our workstation monitors are sRGB and therefore intentionally using a little bit wrong gamma.
I made three more screenshots from Nuke, the first is standard non ACES Nuke with sRGB viewer.
My colors are as expected.
The second one uses ACES 1.0.3 and the Output/sRGB ColorSpace in the Read Node and the D60 sRGB Viewer in Nuke.
The results are quite similar, but the yellow is much more desaturated compared to the first screenshot.
The last one uses Utilities/sRGB/Texture - I expect the max. saturation to be greatly reduced, because as I understand it, the sRGB primaries are placed inside ACEScg, but not scaled at all to change the appearance. What I don’t get is why there seems to be another gamma correction happening.
The other part of my original question was if anyone know how an ACES project with opaque white subtitles should be handled:
Do I really insert white titles with a value of 16 in the image or do I always first apply the RRT&ODT and then add subtitles with a value of 1.0?
I could imagine that titles with white values of 16 will really shine on a HDR screen
The reason for this is that the utility sRGB IDT is a straight sRGB to ACES transform, and does not include an inverse RRT. Therefore the tone-mapping of the RRT is causing the “gamma correction” you describe.
Hi Daniel. Nuke’s default color management does not use the same formulae used in ACES color-space transforms. Particularly in your case, its view node does not implement the same sRGB specifications in the ACES Output Transform.
Effectively Nuke’s and ACES’ sRGB color spaces are different to each other, therefore one cannot simply match footage flagged as sRGB through those two pipelines.
This is not an ACES limitation, rather one of the issues it is trying to solve: by suggesting UX guidelines (as per document ) as well as colorspace definitions.
As for the problem of the white titles, you can simply colorpick the white-level you need “on top” of your viewing colorspace (i.e. on top of the ACES Output Transform) and your application’s color management will revert back to the right ACES2065-1 or ACEScg 16-bit floating-point codevalue.
Especially for video applications though, be always aware of video-level codevalues (e.g. 235 vs 255 codevalue for 8bpc full-white).
And, for the record, the RRT curve, per se, is mathematically invertible. It’s the ODT (i.e. the device-dependent) part of some Output Transforms that might not be so.
I don’t remember seeing anything not invertible in the ODTs (the segmented splines should be as most of the transformations), however the RRT code definitely has some non invertible code, i.e. Red Modifier.
Edit: Actually, there is a clamp in for example transforms/ctl/odt/rgbMonitor/ODT.Academy.RGBmonitor_100nits_dim.ctl:
I think @TooDee was quite clear that he is using Nuke in OCIO ACES mode, not Nuke default, so the colour management is ACES. In his screen grabs the VLUT is clearly sRGB (ACES).
And as @Thomas_Mansencal points out, there is more to the RRT than the curve, and some of those things are not fully invertible.
You can of course do the same in Nuke by using an OCIODisplay node within your node tree, rather than as the VLUT.
For practical reasons, I would default to applying titles after colour rendering, you can then separately control the intensity and colour to create the desired feel - you don’t always want the titles to live in the scene’s world.
The down side is obviously you have to repeat the work for multiple deliverables
On a different tangent, subtitles and captions have traditionally been done at 80-85% diffuse white, not at 100% (1.) because they tend to look a little glaring that way and are hard on the eyes. Even in the film days, the goal was to present the titles as if they were coming off paper ‘cards’. Because the subtitles always have to be readable, this also was easier when peak whites in 709 were only at 1.0. In HDR (or 3D), it is not settled
yet as to where to put the brightness of subtitles, but no more than 90% is a good place to start.
Jim Houston
formerly Pacific Title & Art Studio where we did about 80% of Hollywoods titles for a time.
