AcademySoftwareFoundation
Feature request: OCIO downgrade
Given that OCIO is rapidly developing and changing, we are seeign some issues in production with ocio version support.
Would it be in scope at all to think about a ocio downgrade tool? something that takes lets say a ocio 2.4 aces 2.0 config and downgrades it to 2.2 for nuke support, by baking the new added builtintransforms like appleLog etc to luts?
I think it would really be nice to have a downgrade path.
Also considering that there are some app updates on the horizon for certain tools that enable a gui way of exporting and changing ocio configs, which makes it all way more accessible to average artists - however this would be semi useless if the exported configs cant be used in just slightly older apps.
Hope this makes sense, obviously not urgent just something to think about if thats desiresble , certainly would be nice for us.
I think an OCIO downgrade tool would be extremely useful. Similarly, I've, at times, wished we had a means to selectively validate and/or "toast" (i.e. partially "bake") Processors or GroupTransforms to be compatible with specific earlier versions of CTF (or OCIO)... kind of like how Processor optimizations work, but with options and heuristics for selectively baking and concatenating representations of "unsupported" transforms. (Would also be nice to roll similar options into GroupTransform.write(), to make it easier for folks to kick out approximate CLFs).
This becomes A LOT easier if we're not concerned with OCIO-1 compatibility. Personally, I'd be just fine if the tool only supported downgrading to OCIO-2.1+ compatible configs.
The other sort of tricky thing is, handling of FileTransforms. As far as existing FileTransforms in the Config go, I suppose the tool could either take an OCIOZ archive, or otherwise scan for transforms as if it were creating a new OCIOZ archive; and the tool would either copy or "toast" compatible transforms into a new OCIOZ archive. The tool would also need to bake out any incompatible transforms within the config itself, and re-express the transforms in the Config as FileTransforms referencing the intermediate CLFs.
On a related note, I'd love if the API had a way to automatically dump to an OCIOZ archive a modified version of a Config held in memory, with ad-hoc FileReferences pointing to generated CTFs in place of any LUT1DTransforms and LUT3DTransforms.
