Re: Thoughts on layering of multiple config files
|
Rob Molholm <robert....@...>
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 <jeremy...@...> wrote:
|
|
|