Merging two arbitrary YAML configs seems like a direction in which madness lies.. There's lots of cases where the behaviour would be non-obvious, e.g: * parent defines and uses a 'linear' space, child also defines a 'linear' space with, say, different allocation - what happens? * Does a file-reference in the parent search the child search_path? * If there's a base config, can I not inherit a specific colorspace? * ..and a bunch more I haven't fully thought through (like "would you need to control the order in which views are merged?", "in the child config, could you remove a colorspace from the parent?")
Limiting the scope a bit might make things clearer, e.g something like
colorspaces: - !<IncludeColorspaces> {src: "/path/to/shared/base.ocio", include: [srgb, "*log"], exclude: ['badlog']} - !<Colorspace> name: ...
Where this would just include the colorspace definitions, but ignore anything like the search_path from the included file. If the included config requires LUT's in a certain location, this path would be added to "search_path" as usual.
That said, I don't really understand the benefit of this.. While the current "one config.ocio per project" setup involves some duplication of colorspace definitions etc, I don't see this as a downside.. Either a colorspace never changes (in which case, copying-and-pasting is little hassle), or the colorspace needs changed (in which case, it's useful being able to update new projects without fear of breaking current/finished projects)
It'd be good to have a few clear explanations of workflows where the nested configs would be beneficial (beneficial over alternative approaches like copy-pasting-and-modifying, or Python-generated configs) - Ben
On 27/06/2013, at 3:42 AM, Nathan Rusch wrote: Thanks for the information everyone.
It sounds like the general thoughts in this direction so far are leaning toward the idea of nesting or referencing configurations within each other. While I think this could certainly be useful, it really seems like a layering system would be far simpler to implement, as well as to actually make use of.
My basic thought is that the different configuration files would be completely blind to each other, and it looks like Config::Impl::load() could be safely called once for each file found on the environment variable. With this approach, the burden of making sure you aren't adding references to undefined transforms or colorspaces could fall on the end user (at least initially). Among other things, this would allow for, say, a single application to easily override the definitions for certain transforms, looks, etc. without requiring what would otherwise be a carbon copy of the original config file.
What are the general reactions to configuration layering vs. nesting, or thoughts on the implementation side?
-Nathan
On Tuesday, June 18, 2013 1:05:41 PM UTC-7, Malcolm Humphreys wrote: I was hoping we could use a combination of anchors and references ( http://en.wikipedia.org/wiki/YAML#References) with some kind of special '#include some_other_$(SHOW).ocio' which would be resolved before it gets to the yaml parser inside OCIO.
Support for anchors and references would also allow to reduce a lot of duplication in current profiles while also opening up the possibility of using data from profile segments that get #included.
.malcolm
On 18/06/2013, at 5:55 AM, Rob Molholm wrote: Hey folks,
Although implementation of issue #282 below is still ideal, I have been testing a combination of FUSE and OCIO, using FUSE as a way to abstract database queries, presenting results as "virtual" OCIO configurations to the calling application (using the filesystem hierarchy for baked context). This does have its limitations, but it is one way to centrally manage several configurations. FUSE also works across multiple platforms, which is a bonus.
In production we're pretty much doing as mentioned-- we have a baseline OCIO configuration, which is carried over and modified by a script for each project, and also baked for contexts within a project where the OCIO contexts do not work
...and speaking of including/merging configurations- has it ever been floated to add an OCIO config file as one of the supported file types of OCIOFileTransform? there'd have to be an additional argument to specify a specific color space (or look) out of the included file, but this could be a way of bringing in known complex/grouped transforms, rather than relying on the basics in a single file. The source path of the file transform would be subject to the current context, so you definitely could get crazy with this. Not sure how dependancies from the included color space would be resolved either...
-rob
On Jun 17, 2013, at 6:12 PM, Jeremy Selan < jere...@...> wrote: Hi.
Unfortunately the ability to layer ocio configurations isnt implemented yet, though we do consider it a really good idea. See this existing issue for more information, or to add your thoughts:
In the meantime, we handle this at SPI using python scripts to build configurations for each show. The code is generally similar to this...
Not quite as elegant as being dynamically read on the fly, but it has suited our needs to a high enough degree that this has been a low priority for us in the interim.
-- Jeremy
On Mon, Jun 17, 2013 at 12:41 PM, <nath...@...> wrote:
Hey all,
I hope I'm not spawning a duplicate discussion thread; I did some searching around, but couldn't find anything.
I'm wondering if there has been any discussion about allowing multiple config files to be used to build a single runtime configuration by layering multiple (possibly sparse) definitions on disk. Similar to the PATH environment variable, the final configuration would be built from the "bottom" of the OCIO variable's path list up, allowing files of higher precedence to replace existing definitions within the configuration (to facilitate overrides), as well as add items to it. One goal of this would be to make it easy to propagate changes to "static" pieces of a core OCIO configuration across many shows.
How are people currently handling the possibility of changes to what might be considered the "core" of your OCIO configuration? One option seems to be to have the build script for each show's configuration load a "baseline" config and then amend it or replace certain items (assuming this is possible)...
Thanks for any thoughts,
-Nathan
--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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/groups/opt_out.
|
