Date
1 - 3 of 3
Nested config files...?
|
Hugh Macdonald <hugh.ma...@...>
Nothing like rocking the boat after only just getting on...
I'm still very new when it comes to OpenColorIO, so I have no idea if this has been discussed already and discounted, or whether people have philosophical issues with doing something like this... What do people think of the ability to have nested config files? So you would have a base level config, which would have to have everything that the current one has. You could then have other config files that would supersede, or append to, values in the base. Defined by setting $OCIO to "/path/to/config.ocio:/path/to/another/config.ocio" So you might have a company-wide one, but then a show-specific one that just contains the following. ============================================ ocio_profile_version: 1 displays: default: - !<View> {name: sRGB, colorspace: sRGB} - !<View> {name: rec709, colorspace: rec709} - !<View> {name: Film, colorspace: proj_film} active_views: [sRGB, rec709, Film] colorspaces: - !<ColorSpace> name: proj_film family: proj_film bitdepth: 8ui description: | Display space for film emulation for this specific project isdata: false allocation: uniform from_reference: !<GroupTransform> children: - !<ColorSpaceTransform> {src: raw, dst: lg10} - !<FileTransform> {src: lg10_to_film_project.csp, interpolation: linear} ============================================ This would enable a core facility colour spec to be defined, with tweaks as needed on a per-project basis (based, maybe, on LUTs defined by a DI facility) Another alternative would be to have one config file pointed at by $OCIO something like: ============================================ ocio_profile_version: 1 parent_config: /path/to/a/config/file/to/load/first/config.ocio displays: default: - !<View> {name: sRGB, colorspace: sRGB} - !<View> {name: rec709, colorspace: rec709} - !<View> {name: Film, colorspace: proj_film} active_views: [sRGB, rec709, Film] colorspaces: - !<ColorSpace> name: proj_film family: proj_film bitdepth: 8ui description: | Display space for film emulation for this specific project isdata: false allocation: uniform from_reference: !<GroupTransform> children: - !<ColorSpaceTransform> {src: raw, dst: lg10} - !<FileTransform> {src: lg10_to_film_project.csp, interpolation: linear} ============================================ Thoughts? --
Hugh Macdonald nvizible – VISUAL EFFECTS hugh.ma...@... +44(0) 20 3167 3860 +44(0) 7773 764 708 www.nvizible.com |
|
|
|
DBR - Ben <dbr....@...>
Hm, I quite like the idea, but equally like how simple the configs are.. There are a few technical reasons that nested configs might be a bit confusing: - The most obvious issue is LUT search paths - if the parent profile contains "luts: parents_lut_dir/" and the child contains "luts: childs_lut_dir/", where would you search for a LUT? Only the child (as its' lut: overrides the parent)? Both? The parent's path only for colorspaces defined in the parent etc..?
- Would the parent profile need to be a valid (working) config? If so, it would need to define at least one display and a view.. In which case, would the child profile be capable of removing display devices?
Seems like the main benefit to nested-configs would be tidying the standard colourspaces into a separate file (e.g defining the various common log transforms in one space, rather than copying-and-pasting them everywhere)
Not sure exactly how it would work, but what about a way of bundling one or more colorspace definitions into a file (including LUT's and such)? Then you could include this file by doing something like:
colorspaces: - !<IncludeFile> filepath: /path/to/various_logs.ociospaces - !<ColorSpace> name : etc This would circumvent inheriting of displays/search-paths, but somewhat treads on the toes of https://github.com/imageworks/OpenColorIO/issues/30
On 4 August 2011 18:23, Hugh Macdonald <hugh.ma...@...> wrote:
|
|
|
|
Jeremy Selan <jeremy...@...>
Hugh,
toggle quoted message
Show quoted text
Nested config files are an interesting idea, and I'm all for ideas that make it easier to maintain a bunch of shows in the long term. Let me think about it over siggraph week, and see if I have any further thoughts. One counter argument though... at Imageworks, we have custom profiles for each show, and in ~7 years of using a color pipeline essentially equivalent to what you see with OCIO, we've never yet needed to add this functionality. One of the reasons is that often our shows use very different color pipelines, and the linear connection spaces arent always suitable for the approach you specify. (I.e. a colorspace definition created for the spi-vfx profile wouldnt typically be appropriate for inclusion in the spi-cg profile). Another reason is that at SPI we tend to work on very large productions and thus have the luxury of color customization per show. Perhaps at smaller facilities, with shorter schedule, a master color config approach would be more helpful though? Also, we tend to want to lock shows off in terms of color, and having a single file with all color definitions makes this very easy to guarantee. What color management approach are you currently using? Does it support this type of workflow? If you're interested in prototyping such a workflow in OCIO, you can probably mock it up using the existing public python API. Remember that the API can be used to dynamically load / edit / and save ocio profiles as needed. Example: makeocioshowprofile <master.ocio> <show.ocio> <output.ocio> This script could load master.ocio. Add any additional colorspaces as defined in show.ocio, and save it to output.ocio. (which would then be referenced in the client apps). I'm happy to help with the python configuration manipulation, if you think this approach is interesting. My gut reaction says that this may be a can of worms, though. Configurations are already rather complicated, and only thinly documented. I'd much rather devote our limited development efforts (pre 1.0) to making what we have bullet-proof (in both code, user manuals, and documentation), as opposed to adding new features. As something like this could always be added in a binary compatible manner in the future, there's really no harm in taking it slow. Will you be at Siggraph? I'd be happy to discuss in person if you're interested. Cheers, Jeremy On Thu, Aug 4, 2011 at 3:46 PM, DBR - Ben <dbr....@...> wrote:
Hm, I quite like the idea, but equally like how simple the configs are.. |
|
|