Open dbr opened 4 years ago
The first approach you describe ("OCIO powered mega-LUT") will be mostly supported by CLF/CTF in OCIO v2. You can even use Processor::write()
to losslessly write any processor (comprising your transforms) to a file, which could be referenced by another config. It doesn't answer the cleaner logical switch suggestion, but is a step in the right direction.
We often have transforms which need to vary, say, sequence to sequence.
For example: say most of the show converts to
default_log
to apply a client grade.. except one sequence which needsanother_log
.We currently implement this using the "lut_search_path fallback" pattern. As in, we have a fallback folder containing a fixed filename (usually symlinked to the desired LUT), and create folders for the sequences requiring overrides:
then
lut_search_path
contains something like:So then when the colorspace definition (or look etc) references the pershot.lut:
..it will either find the LUT in
pershot-ZZZ
if $SEQ is set to that, and for all others values of $SEQ it will end up at thepershot-fallback
folder.While this approach works, it is far from ideal. Main issues are:
pershot
, the config no longer inherently describes what this transform actually does)lut_search_path
entries, dummy transforms etc)One idea which was discussed a long time ago was to essentially take a ColorSpace definition config snippet and write this to a file - kind of like an "OCIO powered mega-LUT" file - then reference this in your config using the fallback pattern. This solves points 3 and 4, but not so much the other two points. It lets you switch multiple transforms, but still convoluted/opaque.
A different way this could be approached is to have a "meta-transform" (along the lines of the
GroupTransform
). This meta-transform would have a condition (e.g "is theSEQ
context variable set to a specific value?"), then a transform to use if the condition is met, and and "else" transformOne possible way of encoding this might be (stealing inspiration from Shotgun API's filter conditions):
This would encode the psuedocode logic of:
These
ConditionalTransforms
could be nested inside GroupTransforms or used at top-level of a ColorSpace defintion. It could also support branching from things other than context-vars (potentially things like if it's a CPU or GPU code path, host names, host applications etc etc)While I'm not 100% happy with the above mockup config syntax, I feel the general approach of encoding these conditional explicitly in the config file could be very valuable. Thoughts?