Context/per-shot grades

"dbr/Ben" <b...@...>

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:

slope: [2, 1, 1]
slope: [1, 1, 1]

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

- !<ColorSpace>
name: srgb8_graded
family: srgb
bitdepth: 8ui
isdata: false
from_reference: !<GroupTransform>
- !<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:

- !<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 { to automatically receive all group messages.