-
Notifications
You must be signed in to change notification settings - Fork 481
Description
Configs that directly employ Lut1DTransforms and Lut3DTransforms (i.e., held in memory) cannot be serialized to a YAML stream. This is in contrast to Configs that indirectly reference such transforms via FileTransforms or BuiltinTransforms.
It would be great if we had a few convenience methods to help users automatically and effortlessly create serializable representations of Configs that would otherwise refuse to serialize() to YAML.
A foolproof method for coercing an OCIO Config into a serializable + archivable representation is to bake CTFs of all Lut1DTransforms and Lut3DTransforms to a [custom?] relative location (prepending to the Config search path, if necessary), whose filenames match the cache IDs of Processors containing each transform; and swapping out the Lut1D/Lut3DTransforms for equivalent FileTransform references.
Alternatively, entire ColorSpace / ViewTransform / NamedTransform / Look transform definitions could be serialized to CTFs with more human-friendly filenames, based on the names given to higher-level Config constructs (e.g, "to.ctf")
Eventually, like #2219 hints at, it would also be very cool if we had methods for intelligently exactly representing / approximating Lut1DTransforms as other (serializable) OCIO Transforms, potentially permitting users to convert entirely unserializable Configs into more-serializable Configs, or to otherwise reduce the need to externalize LUTs or OCIOZ files in the first place. Ultimately, I'd love to see something like this tied in to whatever interface we provide for coercing unserializable Configs as a "preconditioning" step; but I think such efforts are probably worth their own GitHub issue...!