jeremyselan
commented
12 years ago Should be consolidated with this: http://opencolorio.org/userguide/contexts.html#per-shot-grades
Closed jeremyselan closed 12 years ago
jeremyselan
commented
12 years ago Should be consolidated with this: http://opencolorio.org/userguide/contexts.html#per-shot-grades
dbr
commented
12 years ago With the consolidation, the "a complete example" section should be updated to use a Look, instead of the confusing pair of colourspaces (lnh and lnh_graded)
(also the github formatting has eaten a few of the <)
Update the looks docs with the recent email info. Also provide an example .ocio configuration demonstrating it.
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:
The src file can be any lut type that OCIO supports. (In this case, it's a file that contains the 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:
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:
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.