1. Messages
  2. Context/per-shot grades

Re: Context/per-shot grades

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

Unfortunately we dont have support yet for environment-driven
numerical parameters. It's something I'd like to add eventually, but
there are few hotter API issues I need to tackle first.

To summarize the current system...

You can reference any envvars in the specification of FilmTransform's
src parameter, either using relative or absolute paths:
Examples:
* <FileTransform>: {src: grade_$SHOT.spi1d}
* !<FileTransform>: {src: /shots/$SHOW/$SHOT/grade.spi3d}

Relative paths are resolved using the config.getSearchPath, which a
colon-delimited list of directory names. These directory are relative
or absolute (relative dirs being relative to the config's local
'working' dir), and both can also contain envvars.

The OCIO::Context is an implementation detail. Unless your application
will want to switch the values during runtime, you dont have to worry
about using the Context class. (When your application is launched,
the environment will be obeyed).

So in the meantime you'll need to write out your color correction to a
fileformat that OCIO obeys. Note that this doesnt have to be a baked
lut though. If your color correction can be represented in the
language of an ASC 'primary grade', I'd recommend just saving out the
ASC xml ColorCorrection element to its own file, and give it a .cc
extension. Or, you could put these all in a single .ccc and specify
which element to load using the envvars. This functionality isnt in
the master branch yet, I'll try to roll these into the master branch
very soon if you'd like it.

Example .cc file:
(Note that the asc does not specify a way to store a single
color-correction alone in it's own file, they only define a collection
of transforms. So i've stolen their xml syntax, put it as the root of
a document, and labelled it 'cc').

<ColorCorrection id="di_look">
<SOPNode>
<Description>
Created by jeremys at 2011-01-03 05:45pm
</Description>
<Slope>
1.000000 1.000000 1.000000
</Slope>
<Offset>
0.000000 0.000000 0.000000
</Offset>
<Power>
1.095000 1.130000 1.385000
</Power>
</SOPNode>
<SatNode>
<Saturation>
1.000000
</Saturation>
</SatNode>
</ColorCorrection>


-- Jeremy

On Sun, Jan 16, 2011 at 6:13 AM, dbr/Ben <b...@...> wrote:
If I understand correctly, the Context allows you to set a search path including env-variables (e.g $SEQ/$SHOT), so you can define a FileTransform, and it'll look in the shot's directory before the "default" directory? (just figured this out after writing the remainder of this email, so it might right slightly oddly..)

I wonder, could (or does) the context system allow parameterised transforms? E.g in pseudo-YAML:

context-values:
 ab:
   ab-123:
     slope: [2, 1, 1]
 default:
   slope: [1, 1, 1]

displays:
 - !<Display> {device: sRGB, name: "Film Graded", colorspace: srgb8_graded}

colorspaces:
 - !<ColorSpace>
   name: srgb8_graded
   family: srgb
   bitdepth: 8ui
   isdata: false
   from_reference: !<GroupTransform>
     children:
       - !<CDLTransform>
         slope: $slope
         offset: [0, 0, 0]
         power: [1, 1, 1]
         saturation: 1
       - !<ColorSpaceTransform> {src: lnf, dst: lg10}
       - !<FileTransform> {src: filmemulation.spi3d, interpolation: linear}


Possibly better to explain what I'm trying to achieve:

Say I have grades for a several shots, which should be used to view the comp (a CDL grade, or printer light offset etc). I could create a group transform containing: the parameterised colour transform, the log'ification and display LUT. Then you'd just need a simple script to populate the config with grade values (e.g from Shotgun)

The same concept could maybe be extended for, say, creating neutrally graded plates (a GroupTransform that linearises and applies a grade), but I can think of various problems/complexities with this, so it'd probably be simpler doing this with a modified version of the ocioconvert tool or something (as grading plates isn't a shot-specific thing, it's a scan specific thing, so the context would have to be based on file paths, which isn't something OCIO could really parse)

Hmm, being able to have per-shot FileTransform's (using the Context dynamic search path) is probably enough, e.g:

children:
 - !<FileTransform>: {src: grade.spi1d}
 - !<ColorSpaceTransform> {src: lnf, dst: lg10}
 - !<FileTransform> {src: filmemulation.spi3d, interpolation: linear}

Although it would be nice to avoid writing a file per shot, and avoid turning a nice simple tuple3f into a LUT or transform matrix (then again, I've done per-shot LUT's in the past and it wasn't a problem, plus those files had to contain both the 1D grade and the 3D display LUT)

Hope some of that made sense - sorry for the slightly long-and-rambling email!
- Ben
Join {ocio-dev@lists.aswf.io to automatically receive all group messages.