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.