I’ve been thinking about this more and more lately; and I do wonder whether a single RRT is a necessary constraint in the age of technologies like OCIO, AMF, and CLF.
OCIO-v2 lets one unambiguously define, communicate, and procedurally traverse graphs mapping ACES2065-1 to arbitrary output targets via arbitrary intermediate ViewTransforms on demand, a la architectural analogs to the following style pipelines:
An OCIO config is capable of defining and procedurally traversing the graph containing all paths from AP0 colorimetry —> output light via the one (of few) mastering-target-referred ViewTransforms demanded by one (of many) display device / encodings.
OCIO is capable of representing that path equally well as shader code or Academy CLF.
Alternatively, Academy AMF sidecar data provides a means to describe specific transform chains per-clip / per-rrt-version / per-output-transform permutations; which, in turn, can also be baked to CLF via OCIO (feature-pending).
On one end, this doesn’t necessarily preclude the use of a single RRT; and on the other end, it doesn’t preclude the use of multiple hypothetical Academy and/or vendor-provided DRT “families”.
This is a really long winded way of saying it, but ALLS I’M SAYIN IS, as brilliant as a single RRT architecture is, viable, open, Academy-sponsored (directly or indirectly) means for alternatives have emerged over the past decade, congruent with how ACES is often ab/used in production; and if we can agree and take for granted that we already have (and use) the necessary technology for specifying and generating program-specific • output-specific transforms, the entire world is our oyster.
Of course, I’m conveniently sidestepping the problem of tracking LMTs to the DRT families / master-variants to which they refer, depending what we decide to do with ViewTransforms; but we’re still taking finite permutations of manageable complexity.
The entire world. Our oyster. Just saying.