Re: Review: FileTransform supports .cc and .ccc files

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

On 22/01/2011, at 12:59 PM, Jeremy Selan wrote:

This adds support for loading .cc and .ccc files in the FileTransform
operator / node.
.CC files are the ASC CDL <ColorCorrection> text stored in a single file
.CCC files are the ASC CDL <ColorCorrectionCollection> group of
transforms (a well defined format).

To support the .ccc format, a new parameter on filetransform is added,
"cccid".   When a .ccc file is specified, this is required to
determine which transform contained in the list is used.  The new
cccid parameter supports the Context lookups (woohoo!), so one can
define it conveniently using an environment variable.  This should
fully address the context/per-shot grade workflow mentioned above by

This is great. Nice and intuitive \o/

!<FileTransform> {src: grades/grades.ccc, cccid: "beauty/${SEQ}/${SHOT}"}

..or, could split the grades into one file per seq and do ({src: "grades/${SEQ}_beautygrades.ccc", cccid: "${SHOT}"}) etc

..which worked pretty much exactly how I expected.

This seems like it could be a good way to (at some point) implement env-dependant transform parameters, e.g:

- !<ExponentTransform> {file: "settings_${SHOT}.yaml", key: "exponent/${SHOT}", direction: inverse}


    values: [2.2, 2.2, 2,2, 1]

..but that'd be a trivial feature, as the CDL grades will more than suffice! Most of the grades I'd need to apply are in code value/printer light offsets, which map directly to the slope control, if linearising using "Josh Pines log-lin"

Started writing a "contexts" page for the docs. Does this explanation match with how you intended them to work?

There is one known bug in this implementation; when I exposed this new
cccid property as a String_Knob in nuke, when I update the value in
the interface it does not appear that the value is being incorporated
into the Op's hash id.  Is this a limitation of Nuke? An issue with
using PixelIop(s)?   I have confirmed that if I use the File_Knob UI
type, everything works as expected...

Not sure why the String_Knob would not be automatically added to the hash, but you could manually append to it by doing something like:

void NodeThingy::append(Hash& hash)

I wonder, could the cccid's be presented in a drop-down, similar to the colour-space listings? Might circumvent the oddness too... Also, it'd be nice if the cccid field only appeared when loading a .ccc file (I think you just need to set the invisible flag on the knob in _validate)

Join to automatically receive all group messages.