Re: Nested config files...?


Jeremy Selan <jeremy...@...>
 

Hugh,

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..
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:

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

Join ocio-dev@lists.aswf.io to automatically receive all group messages.