Re: Nested config files...?


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