1. Messages
  2. advice, supporting dynamic color space additions to config

advice, supporting dynamic color space additions to config

Haarm-Pieter Duiker <li...@...>
 

Hello,

I'm working on a project that has a base set of well-defined transforms and a more extended set of transforms/color spaces that are less well-defined. The 'less well defined' transforms are going to come from 3rd parties and will likely be delivered after a config including the main set of 'well-defined' transforms is locked down and released to a number of users.

I'm hoping for a bit of advice from the list on the best approach to deploying this config, and potential feature additions to OCIO to support this situation (if they're deemed in the best interest of the overall project, of course). The options that I see are:
  1. Rerelease a config every time there is a new 3rd party transform
    • Pros
      • There would be one source of 'official' configs
    • Cons
      • Lots and lots of configs. Users would have to update constantly.
      • Different apps typically source their own set of configs. Updating configs for all apps could be tedious. For large shops and people comfortable with environment variables, this isn't a problem. For smaller shops and individual users, that might be a blocker.
  2. Users regenerate configs dynamically as 3rd parties make transforms available
    • Pros
      • Users do this on their own, as they need.
    • Cons
      • There is another process to support. What happens if their are bugs?
      • A splintering of configs. Debugging an 'official' config becomes more complex if the generation process has lots of options.
  3. Extend OCIO to allow some form of automatic, dynamic color space addition
    • Pros
      • Allows a clean separation between the official config and 3rd party transforms. Each data set can evolve on its own.
    • Cons
      • Features to support this need to be defined
      • Workflow for deploying new color spaces / transforms needs to be defined
Are there better approaches to that problem? The 3rd party transforms aren't show, shot or sequence LUTs so just substituting LUT paths based on environment variables isn't enough. They will need to be named and differentiated from each other. Additionally, the number and names of the color spaces/transforms can't be known before the main config is released.

This email was originally going to be a question about 'What happened to the idea of having an $include statement' but I figured that that was just the tip of the iceberg.

Any thoughts or advice you can provide would be appreciated.

Thanks,
HP
Join {ocio-dev@lists.aswf.io to automatically receive all group messages.