Hi Malcolm and Jeremy,

Thanks for the docs page. It is very helpful. Clearer now on how to have a single ocio config for a show. And yes, Jeremy that would be excellent if you can show me (or add to the docs) the way to allow the per shot grades to live in directories that are not necessarily under the main config directory ala Sony's (and DD's)  workflow.

If it is a matter of extending the OCIO search path by the additional grade directories, that sounds pretty straightforward.

Thank for your prompt responses, guys,

-Blake

Per Shot Looks:

Step 1: Setup a Look

A look is a top-level OCIO configuration object.  Conceptually, it's a named transform which gets applied in a specific color space.  All of the changes below to the .ocio configs can be done manually by editing the text, or using the python API.

Example OCIO Configuration:

looks:
  - !<Look>
    name: di
    process_space: rclg16
    transform: !<FileTransform> {src: look_di.cc, interpolation: linear}

The src file can be any lut type that OCIO supports. (In this case, it's a file that contains the <ColorCorrection> element from a CDL file.)  You could also specify a .3dl, etc.

Once you define a look in your configuration, you'll see that the OCIOLookTransform node in Nuke will provide the named option.  In this example, the 'DI' look conceptually represents a look that will be applied in DI.  Other look names we often used are 'onset', 'editorial', etc.     The process_space implies that the transform should be applied in that space.  I.e., if you provide linear input to the OCIOLookTransform node, the pixels will be converted to rclg16 in this example before applying the cc.

Step 2:  Update the Display to use a look.

Example:

displays:
  DLP:
    - !<View> {name: Raw, colorspace: nc10}
    - !<View> {name: Log, colorspace: rclg10}
    - !<View> {name: Film, colorspace: p3dci16}
    - !<View> {name: Film DI, colorspace: p3dci16, looks: di}
  sRGB:
    - !<View> {name: Raw, colorspace: nc10}
    - !<View> {name: Log, colorspace: rclg10}
    - !<View> {name: Film, colorspace: srgb10}
    - !<View> {name: Film DI, colorspace: srgb10, looks: di}

You can optionally specify a 'looks' tag in the View tag, which will apply the specified look(s).  This lets application in the viewer provide options which do (or do not) use the looks.   Option for super advanced users:  The looks tag is actually a comma-delimited list supporting +/- modifiers.  So if you you wanted to specify a View that undoes DI, and then adds Onset, you could do "-di,+onset".

Step 3:  Get per-shot looks supported.

In the top example, look_di.cc, being a relative path location, will check each location in the config's search_path.  The first file that's found will be used.

So for
search_path: luts
only the 'luts' subdir relative to the OCIO config will be checked.

But if you specify:
search_path: /shots/show/$SHOT/cc/data: luts/ocio
the directory /shots/show/$SHOT/cc/data/  will be evaluated first, and only if not found luts/ocio will be checked.

envvars, absolute, and relative paths can be used both in the config's search_path, as well as the View's src specification.

Example:
  - !<Look>
    name: di
    process_space: rclg16
    transform: !<FileTransform> {src: looks/$SHOT_di/current/look_$SHOT_di.cc, interpolation: linear}

Note that if the per-shot lut is not found, you can control whether a fallback lut succeeds based on if it's in the master location.  You can also use this for multiple levels (show, shot, etc).

Advanced option: If some shots use .cc files, and some use 3d-luts currently there's no simple way to handle this.  What we'd recommend as a work around is to label all of your files with the same extension (such as .cc), and then rely on OCIO's resiliance to misnamed lut files to just load them anyways.  Caveot: this only works in 1.0.1+ (6da3411ced)

Advanced option:  In nuke OCIO nodes, you often want to preview looks 'across shots' (often for reference, same-as, etc).  You can override the envvars in each node, using the 'Context' menu.  For example, if you know that $SHOT is being used, in the context key1 you should specify 'SHOT', and the in value1 specify the shot to use (such as dev.lookdev).

Advanced option:  If you are writing your own OCIO integration code, getProcessor will fail if the per-shot lut is not found, and you may want to distinguish this error from other OCIO errors.   For this reason, we provide OCIO::ExceptionMissingFile, which can be explicitly caught. (And then handled using OCIO::DisplayTransform::setLooksOverride())  I'd expect image flipbook applications to do this approach.



-- Jeremy