Thanks @Thomas_Mansencal . I’d be happy to discuss what makes sense for this and how I can help support the needs of products like OCIO moving forward. I welcome any ideas or requests on files that would be useful to add (like the JSON file manifest you mention) or restructuring to make tracking the transforms and any changes to them easier to integrate into products. We have a great opportunity in the prep for ACES 2.0 to try to “do it right” based on things we’ve learned or realized since v1 went out.
We also have need to officially set the form of the transform ID tokens (and fix broken ones)
The “Where? How?” that you ask also extends to other aspects of the maintained ACES components. I would also like to think about and discuss:
- the tokens and ordering that go into the filename string for customized ODTs produced using the parameters but outside the commonly used stock transform that we provide as presets. (e.g. does the filename disclose all the parameters that are set in the Output Transform? - peak luminance, CAT used, EOTF, primaries, limiting primaries, etc. Is that a good thing or a bad thing to have verbose filename? Or can this information be communicated in another way?
- The entire architecture of the transforms (directory hierarchy and what is stored where?)
- what format are they provided in? CTL, DCTL, CLF, flspace, some mixture of the above?
- IDTs separated? how are user-submissions delineated from those vetted by the manufacturer or, at the very least peers?
- “versioning” (whatever that means) and the best way to track it and communicate it
- anything else related to how the code is stored / maintained that has irked people over the years