Re: what to call āD60 Sim modeāā¦ well, itās easier than saying, ānot-chromatically-adapted-to-the-output-device-calibrated-whitepointā modeā¦ maybe āACES Creative Whiteā? Thatās how I normally think of it.
Re: naming, tokenization ā I strongly agree with @mplec ā intelligibility and consistency trumps brevity and convenience. Respectfully, I find it less confusing ā visually, conceptually ā if all output transform names err on the side of redundancy, so long as itās easy to determine what the differences and similarities are among a list of ODTs. In fact, as far as file names go, I wouldnāt mind if each token was populated for each transform, so information about each transform could be easily parsed from the filename without resorting to fancy logic. Like, if weāre gonna start listing midpoint luminances, Iād like to see them listed for the 4.8nits default cases as well.
What isnāt helpful, to me, are shortcuts, abbreviations, and assumptions. I have a veritable closet filled with LUTs from various vendors and shows that use obscure shorthand to convey allegedly meaningful information. If something is meant to be implicitly meaningful, it shouldnāt require a decoder ring. Any more than colorscience requires in the first place, anyway.
By the same token, I couldnāt agree more with @walter.arrighetti ā UUIDs are the way forward, in terms of evolving ACESclip / CLF workflows and color pipeline APIs, and communication in general. Perhaps an official schema for UUIDs / associated metadata ā in the case of ODTs, signal range, peak white, gamut limiting, etc. ā and, indeed, āCTL moduleā (since CTL does depend on filenames, after all), maybe āshort nameā if youāre not into the whole brevity thingā¦ enough information to uniquely identify a reference implementation (expressed as CTL module filename on disk, or symbolically with MathML, or a symbol from the SMPTE metadata registerā¦), and enough metadata to provide users and vendors with a way to not only name luts or present transforms as verbosely or succinctly as oneās heart desires, but also imbue a layer of intelligence to the CTL library that can help to reconcile differences between the āmodelā and the āviewā, especially as the two become increasingly abstracted (in terms of ACES relative to other systems, and within ACES itself).
(A part of me does feel that using straight up uuid4 hashes is the way to go, to enforce use of ACESclip / CLF mechanisms, but weāre far from there yet, and that seems a bit draconian and opinionated)
Relatedā¦ what about the dreaded LMT+RRT+ODTā¦ you know, the ones that concatenate on the front end one of those LMTs that serve to āreplaceā the RRT with another, most often display-referred rendering. For sake of argument, letās just say, a given show has decided to work under the ACES RRT, but for each device in the pipeline, thereās a matching LMT that needs to be applied, something like (AP0-to-AP0-limited-to-LogC) --> (K1S1 Tonemap + inv-OETF + LogC-to-deviceRGB + OETF) --> (invRRT+invODT). And this needs to be applied directly before the RRT.
In other words, we live in a world where productions employ show LMT+RRT+ODT concatenated transforms āhijackā RRT rendering (plus or minus gamut compression and desaturated yellows); which, in turn, means standard ACES 1.0 LMTs wonāt perform as expected (without doing anything even more contrived); and all āLMTsā created under the LMT+RRT+ODT are, defacto, LMT+RRT+ODT-referred, instead of RRT-referred.
So:
- Should we have a way to refer to LMTs that override the RRT look, and must be concatenated with a specific RRT+ODT transform? The last thing I want to do is introduce a new acronym, but it is important to differentiate, for lack of a better term, āanti-RRTā LMTs that behave differently from, and have different implications from, regular LMTs?
- Likewise, how to differentiate between standard LMTs and looks created under āanti-RRTā LMTs?
- Similarly, should there be a way to refer to LMT+RRT+ODT transforms thatās a little more evocative of whatās taking place? I suppose thatās what the Target Rendering Transforms and Device Encoding Transforms are intended to generically encompass, but those terms really arenāt used anywhere, and they donāt do much to differentiate one type of rendering transform from another in any practical sense.
I donāt have any particularly smart suggestions, Iām more just curious to hear other peopleās thinking about this ā itās not a concept that sits comfortably within the ACES paradigm, and itās conceptually very confusing to just under 100% of the human populationā¦ but it does seem to me that we need a naming convention for LMT+RRT+ODTs, as well as for the atypical-LMTs in that are specifically LMT+RRT+ODT-referred or āanti-RRTā-referred, because, even though itās tempting to think of partially-implemented ACES pipelines as outside the scope of ACES concerns, for ACESclip to be successful, and in order to communicate and automate effectively, itās something worth brainstorming about.
Damnit, shouldāve saved it for another thread.