I’ve been asked to create an ODT for an animated feature, so serve:
Texture artists working in Mari on Linux
Lighters who are reviewing shots in Nuke
My objective was to create an ODT for DisplayP3 (which is essentially sRGB but with P3 primaries). This seems like it has potential as an alternative to sRGB that takes better advantage of the available gamut on our hardware.
(We’re calibrating Eizo CG2730 monitors with DisplayCal to generate a per-display .icc profile for CentOS 7.4).
I’ve been using the OCIO tool ‘generate_config’ on a custom CTL file that was largely adapted from the sRGB ctl script in OCIO 1.0.3. What I find with both my DisplayP3 ODT and OCIO’s default sRGB ODT is that the luminance is reduced to about 0.83 or 0.81 respectively, so relative to other elements displayed on the screen, a white image viewed in Nuke with the ODT will appear grey.
I’m getting some pushback from my supes about this and they’ve asked me to create an ODT that employs the display’s full available luminosity (so white looks white).
Should I understand from @Thomas_Mansencal’s comment here that this apparent drop in luminance is not just to be expected, but desirable?
If that’s not the case, I hope you will humor some questions about what I should adjust in the CTL to build an appropriate ODT.
@Thomas_Mansencal’s comment sums up the logic well. I agree that an ACES [1.0 1.0 1.0] coming out at about sRGB value of about [.81 .81 .81] is a desirable feature. The key here is that specular highlights and other “super bright” objects in the scene will have ACES values greater than 1.0. Without leaving this headroom for those object in sRGB space, they would appear unnaturally clipped in sRGB. This technique also used in other legacy color systems such as Rec709 where it’s typical to have a scene object with 109% reflectance end up at a Rec709 code value of 1.0 (full range). The ACES SDR transforms place scene diffuse white at a display code value consistent with other cinema-based renderings.
Adding to @Alexander_Forsythe’s comment, the output of the ODT does cover the full range of the display. It is simply that the brightest whites will only occur for ACES values significantly higher than 1.0. The ODTs will peak at ACES values of about [16.3, 16.3, 16.3] which is just over four stops above diffuse white.
If the ACES image data going into the Output Transform (RRT+ODT) does not include values above 1.0, that suggests that it is not truly scene-referred ACES image data, but is output referred, perhaps with tone mapping already baked in by the renderer.
If the ACES image data going into the Output Transform (RRT+ODT) does not include values above 1.0
I think a lot of the dissonance has been for Mari users. I guess a ‘value above 1.0’ in the context of a texture would mean that the surface is emissive? That’s probably not something we see too often.