Today's Topic Summary

Group: http://groups.google.com/group/ocio-dev/topics

Digest for ocio...@... - 5 Messages in 2 Topics [1 Update]
Accommodating per-shot grades [2 Updates]loo
PackedImageDesc memory usage [1 Update]

 Digest for ocio...@... - 5 Messages in 2 Topics

Jeremy Selan <jeremy...@...> Dec 19 11:41AM -0800

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




 Accommodating per-shot grades

Brendan Bolles <bre...@...> Dec 19 11:22AM -0800

On Dec 17, 2011, at 2:00 AM, Malcolm Humphreys wrote:

http://opencolorio.org/userguide/contexts.html#per-shot-grades

If it is it would be great to know so we can improve on it.

I see that the the machinery for handing per-shot LUTs (aside from
environment variable hacks) seems to be there in the form of "Looks", with
functions in OCIO::Config for getting a list of looks and
OCIO::DisplayTransform has functions using them. Is there a sample
configuration available with looks set up?


Brendan



Paul Miller <pa...@...> Dec 19 01:25PM -0600

On 12/19/2011 1:22 PM, Brendan Bolles wrote:

http://opencolorio.org/userguide/contexts.html#per-shot-grades

If it is it would be great to know so we can improve on it.

I see that the the machinery for handing per-shot LUTs (aside from
environment variable hacks) seems to be there in the form of "Looks", with
functions in OCIO::Config for getting a list of looks and
OCIO::DisplayTransform has functions using them. Is there a sample
configuration available with looks set up?

I used the ociodisplay example code and the Sony vfx sample config to
get my looks/views stuff hooked up.



 PackedImageDesc memory usage

Jeremy Selan <jeremy...@...> Dec 19 10:32AM -0800

GetProcessor calls are moderately fast after the first time. They are
currently not cached internal to OCIO, but internal caching is on my short
list to add soon. One getProcessor per software render is fine. (One per
scanline, probably not.)

-- Jeremy





You received this message because you are subscribed to the Google Group
ocio-dev.
You can post via email.
To unsubscribe from this group, send an empty message.
For more options, visit this group.