Custom ODTs in the wild

Discussions - ACESNext VWG – Output Transforms
1

After listening to the workgroup meeting, I’d be curious to hear what custom ODTs people are rolling/using in the wild, and what sort of production issues they’re solving with them.

I’ve had to put together a few:

Gamma 2.2, sRGB primaries, D60sim, dim surround.
I’ve run into a pretty common situation where Applications are handing off pixels to displays which don’t use an sRGB curve directly. Rather they seem to be expecting applications to hand off sRGB data, then use OS level colour management to deal with mapping to a display with a simple 2.2 gamma curve. Some apps seem to bypass the OS level colour management, so on these systems the only way to get a sane display is to have an ODT that outputs simple 2.2, not a true sRGB curve.

I feel like it’s about 50/50 if any specific system is better off running a true sRGB curve or 2.2.
I also feel like a lot of complaints about ACES being too contrastly actually come back to this issue (especially with people kicking the tyres on a desktop PC).

P3-D60 - 250nit semi HDR
This is a bit oddball, but we have been playing around with running HP Dreamcolor 27s with their Luminance maxed out to 250nits. We rolled a custom set of segmented_spline_c9_fwd coefficients to give us an extra stop and a half of highlight info. You pay for it at the bottom end with proportionally crappier black levels, but for bright footage it’s pretty useful.

P3-D60 - 250nit semi HDR - (100nit sim)
As above, but simulating the look of the 100nit output on a display running at 250nits.

HTC Vive - 200nit, Vive primaries and whitepoint (D60 sim), dark surround
Similar development process to the 250nit dreamcolour ODT, but with a display calibrated to Vive primaries. 1 stop of additional headroom. Assumes viewer is in a black void, so dark surround.

Rec.2020 ST2084, 1000nit (D60sim)
Same as the stock one, but producing D60, not D65. (Sounds like this issue is more complicated that I first thought, but it’s working OK for us so far.)

Rec.2020 ST2084, 1000nit (D60sim) - 100nit sim
We have a playback setup where we can easily change display transform, but it’s like 15 steps to change the display’s expected input. We want to be able to quickly switch between 1000nit output, and 100nit output, so we have an ODT that takes the output of the 48nit c9 spline, scales it from 48nits to 100nits, then encodes it with the PQ curve. So far it seems to be working as expected.

AP1 48nit Display, AP1 primaries, gamma 2.6
A custom space for mattepainting in Photoshop.
The concept being that Photoshop is really most comfortable working display referred, so why fight it. We have a custom ODT that uses AP1 primaries (protecting all reasonably exposed ACEScg colours) and the 48nit splines, we then tag those images with an ICC profile describing that space, and let PS handle the actual display. We then have an inverse of that to come back into linear land.

What else are people doing?

1 Like
2

Thanks @alexfry! This is huge in helping us make sure we’ve got all the right options in any sort of parametric ODT algorithm. This is also quite useful for helping us define use cases for the ODT end user documentation.

I’d also love to hear what other ODTs people are cooking up to deal with needs not addressed by the current set.

3

I’m really glad you mentioned this use case.

Many times I’ve made my own custom ODTs that re-encode the output colorimetry so that it can be displayed in a different monitor setup and still look correct. I do this for the same reason as you, it’s much easier to toggle the display transform than to go through 15 display menus to change the monitor setup.

For example, I’ve previously encoded the P3D60 48-nit output as Rec.2020 ST-2084 so that I can show the differences between the highlights/shadows and gamuts on the same monitor setup (Rec.2020 ST-2084).

The ability to “gamut-limit” or “simulate” within a different primary encoding was listed as a feature but it’s important that we’re able to do this for dynamic range limiting and/or simulation as well.

1 Like
4

I’ve done the same myself, for example creating an ODT which renders the Rec.709 100nit ODT on an X-300 set to ST.2084/Rec.2020, to easily toggle HDR/SDR. I included the dark to dim and desaturation steps from the Rec.709 ODT, which the approach described by @alexfry would appear not to do (unless I misunderstand). Any thought on whether those should or should not be included?

5

Yeah, I did indeed skip over the dark to sim surround.
(somewhat without thinking about it)

This is another one of those subtle style inconsistencies between ODTs.
In the Rec709 ODT, “dark to dim” is an explicit step.
In ST2084 it’s implied as part of the c9 tonescale.

I didn’t really think about it too much as we generally work with the P3D60 ODT here. For historical (pre ACES) reasons, we have handled the "dark vs dim’ question by running our P3 desktop displays at gamma 2.5 rather than 2.6.
Which works out at an effective Gamma shift of 0.961538 vs the 0.9811 used by darkSurround_to_dimSurround. (we make no equivalent sat tweak)

In retrospect I should have rolled that into our 100nit sim.

6

Yeah … exactly. I’d personally love to see if we could leverage some CAM math/concepts to handle this instead of what we’re doing now.

1 Like
7

That’s exactly the sort of undocumented decision referred to in the RAE document. I would be easy to think that the dark to dim step was not included in the ST2084 ODTs. Its inclusion in another step is not obvious.

1 Like