Review: FileTransform supports .cc and .ccc files

[Jeremy Selan]

Commits:
http://github.com/jeremyselan/OpenColorIO/commit/843407c6a15df2afa817412614d3d6606d2fa613
http://github.com/jeremyselan/OpenColorIO/commit/dd77b2c5b789d56d8043a33a2e4bea7e99886f2a

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/64

Prior Thread:
http://groups.google.com/group/ocio-dev/browse_thread/thread/61f660d1eb96121b

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
Ben.

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...

-- Jeremy

[dbr/Ben]

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
Ben.

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}

..and

exponent:

  ab-123:

    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?

http://dl.dropbox.com/u/796113/ocio_docs_temp/Contexts.html

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)

{

  hash.append(cccid);

}

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)

[Jeremy Selan]

Nice job on the docs. By all means, check them in! (Even partial
docs are better than nothing). :)

> I wonder, could the cccid's be presented in a drop-down, similar to the
> colour-space listings?

I like this, but I'm not sure that there's a nuke UI widget rich
enough for this behavior. What we want is a popdown that lets you
choose from a bunch of pre-defined options, but also lets you type in
new values (such as envvars). Im not sure that nuke popdowns can
allow text entry capability. The other difficulty is that in nuke if
you use the popdowns, the underlying value is an int index rather than
a string. This sucks because if you were to update the array, change
the underlying value, etc, the only precious data for nuke is what
order it was in the list. (Whereas in our case the value is precious).
So I think it's safer to keep it a string for now. But... what if
we added a button that when pressed provided a popup for the user?
(Calling out to OCIO to enumerate the options). That would make it
convenient + keep data value 'native'.

I like the use of the invisible flag. I'll investigate setting it up.

-- Jeremy

[Malcolm Humphreys]

LGTM

.malcolm

[Malcolm Humphreys]

Hi Ben,

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

http://dl.dropbox.com/u/796113/ocio_docs_temp/Contexts.html

I love docs :) (because of my horrible memory)

My main comments would be I would tend to aim 'contexts' being used as part of the complete viewing transform. Right now it reads as though we recommend having viewing 1D/3D luts per shot / context which I don't think is the case.

It would be great to restructure this a bit so the idea of contexts being part of the viewing transforms comes through.

eg a typical setup could be (order depending on the production requirements)

scene-linear

    `- balance grade .cc or .ccc (Context Controlled)

        `- creative grade .cc, .ccc or .spi1d (Context Controlled)

            `- toLog1d

                `- LogtoDevice3d

.malcolm

[dbr/Ben]

On 23/01/2011, at 4:39 PM, Malcolm Humphreys wrote:

It would be great to restructure this a bit so the idea of contexts being part of the viewing transforms comes through.

Good point. I've renamed the first section "A contrived example", which just explains using env-vars to find a LUT. The second example is more practical, and applies the grade, then a lin-to-log/3D LUT.

http://dl.dropbox.com/u/796113/ocio_docs_temp/Contexts.html

The final one is incomplete, but (attempts to) explains the balance/creative grade workflow. Not sure how to configure the graded linear space. e.g for the steps

- Raw log .dpx

- lg10 to lnh

- Apply "working" balance grade

- Comp

- Reverse balance grade

- Beauty grade

- lnh -> lg10

- lg10 to sRGB

..you could add a lnh_graded space:

- !<ColorSpace>

  name: lnh_graded

  family: ln

  bitdepth: 16f

  from_reference: !<FileTransform> {src: balance_grades.ccc, cccid: "${SHOT}"}

Then if you transform from lg10 to lnh_graded, it would apply the lg10->lnh, and lnh->graded

Does this sound reasonable?

[dbr/Ben]

On 23/01/2011, at 4:41 AM, Jeremy Selan wrote:

But... what if
we added a button that when pressed provided a popup for the user?
(Calling out to OCIO to enumerate the options).  That would make it
convenient + keep data value 'native'.

This sounds like a good solution, much less error prone than storing the dropdown in the node itself.

The J_3Way node (http://major-kong.blogspot.com/2010/01/jops-10v1a5-released.html ) has a nice UI to load a grade from a .ccc file - when you click the "Import" button, you get a dialog with a drop-down of all the ID's, and it shows a preview of the values, and the description:

http://i.imgur.com/Tesy4.png

Something like this would be simple to do. Could allow an arbitrary string input with a "<Custom>" item in the drop-down, which reveals a string input knob.

[dbr/Ben]

Oh,

https://github.com/dbr/OpenColorIO/commit/0247f16ae202eeb5316f695c1310dac523272a0e

On 23/01/2011, at 4:41 AM, Jeremy Selan wrote:

[Jeremy Selan]

LGTM, committed.
Thanks!

-- Jeremy