advice, supporting dynamic color space additions to config


Osiris Perez <osiris.pe...@...>
 

Same here. We can easily do this through the API by re-generating configs on the fly as outlined in this thread. However, 3rd party tools that have standard OCIO integration are not aware of our changes. 

Having this support natively would make it easier to support global studio settings and show/project overrides throughout the pipe without having to re-write or work around 3rd party implementations. 

 


On Thursday, 25 September 2014 16:15:21 UTC-7, Steve Agland wrote:
I've also been thinking about the general idea of configs "inheriting" from one another. I haven't delved far into the API for manipulating configs yet, so perhaps there is some support there if you're okay with dynamically creating configs on the fly.

It'd be great if there was a formal way to have a "global" config from which "show" configs (or some other more specific context) can be automatically derived with some overrides. Overrides could include defining new color spaces, limiting/extending the available display/view options, reassigning "roles" etc.

Steve


On 26 September 2014 05:16, Haarm-Pieter Duiker <li...@...> wrote:

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.


Steve Agland <sag...@...>
 

Yes, this is basically what I was thinking. It'd probably work for us.

On 26 September 2014 10:50, Haarm-Pieter Duiker <li...@...> wrote:
If you're working in a single facility and have some way of prompting configs to be regenerated, the Python API gives you most of the functionality needed for an inheritance model. 

Something along the lines of a 'global' config module which defined the base color spaces, views, displays and so on followed by show/shot/sequence specific modules that could import that global config module, use it to generate a Python config object and then modify that config object as necessary before writing the config to disk could work for a single facility.

HP





On Thu, Sep 25, 2014 at 3:53 PM, Steve Agland <sag...@...> wrote:
I've also been thinking about the general idea of configs "inheriting" from one another. I haven't delved far into the API for manipulating configs yet, so perhaps there is some support there if you're okay with dynamically creating configs on the fly.

It'd be great if there was a formal way to have a "global" config from which "show" configs (or some other more specific context) can be automatically derived with some overrides. Overrides could include defining new color spaces, limiting/extending the available display/view options, reassigning "roles" etc.

Steve


On 26 September 2014 05:16, Haarm-Pieter Duiker <li...@...> wrote:

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.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


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

If you're working in a single facility and have some way of prompting configs to be regenerated, the Python API gives you most of the functionality needed for an inheritance model. 

Something along the lines of a 'global' config module which defined the base color spaces, views, displays and so on followed by show/shot/sequence specific modules that could import that global config module, use it to generate a Python config object and then modify that config object as necessary before writing the config to disk could work for a single facility.

HP





On Thu, Sep 25, 2014 at 3:53 PM, Steve Agland <sag...@...> wrote:
I've also been thinking about the general idea of configs "inheriting" from one another. I haven't delved far into the API for manipulating configs yet, so perhaps there is some support there if you're okay with dynamically creating configs on the fly.

It'd be great if there was a formal way to have a "global" config from which "show" configs (or some other more specific context) can be automatically derived with some overrides. Overrides could include defining new color spaces, limiting/extending the available display/view options, reassigning "roles" etc.

Steve


On 26 September 2014 05:16, Haarm-Pieter Duiker <li...@...> wrote:

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.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Steve Agland <sag...@...>
 

I've also been thinking about the general idea of configs "inheriting" from one another. I haven't delved far into the API for manipulating configs yet, so perhaps there is some support there if you're okay with dynamically creating configs on the fly.

It'd be great if there was a formal way to have a "global" config from which "show" configs (or some other more specific context) can be automatically derived with some overrides. Overrides could include defining new color spaces, limiting/extending the available display/view options, reassigning "roles" etc.

Steve


On 26 September 2014 05:16, Haarm-Pieter Duiker <li...@...> wrote:

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.


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