@zachlewis, thanks for backing both of my petitions:
- naming-convention templating for Input/Output Transforms (and other color transformations)
- adding MIC (intergrity-checking) / referencing capabilities on pre-defined color-transforms (e.g. CTLs, LMTs, …).
I think an Academy-supported online registrar service – at least for the original core components and CTLs provided in the official ACES releases, would be beneficial. This may “proxy” the transforms back directly to the .ctl files in the GitHub repositories.
As regards a naming for LMT+RRT+ODT combinations, I still don’t think it’s a good idea.
- First of all, RRT and ODTs are now “ACES internal” components; they should never be referneced individually in UIs (and UX documents), and be only referenced together by the applications as the Output Transforms. BTW: the same goes for IDTs becoming the Input Transforms.
- Even if LMTs can be used for “undoing” the effect of the ACES RRT and replace it, overall, with a customized tone-mapping (which is called, in FilmLight’s color-sicence, a “display-rendering transform” ― or DRT), this is not really allowed in ACES 1.0. Not because of creative reasons, but because it breaks output-device interoperability with all those products with limited-to-none capabilities to appply LMT(s) in between.
So I’m in favor of better naming LMTs ―even when used as additional creative tone-mappings like a “show LUT”― but I’d never “pre-bake” combinations of LMTs with Output Transforms and ship them with a default release of ACES ― unless for a very good reason dictated by a “solid” production workflow.