Date
1 - 9 of 9
Review: FileTransform supports .cc and .ccc files
|
Jeremy Selan <jeremy...@...>
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" <b...@...>
On 22/01/2011, at 12:59 PM, Jeremy Selan wrote:
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?
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 <jeremy...@...>
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 theI 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 <malcolmh...@...>
LGTM
toggle quoted message
Show quoted text
.malcolm On 22/01/2011, at 1:29 PM, Jeremy Selan wrote:
Commits: |
|
|
|
Malcolm Humphreys <malcolmh...@...>
Hi Ben,
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" <b...@...>
On 23/01/2011, at 4:39 PM, Malcolm Humphreys wrote:
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. 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" <b...@...>
On 23/01/2011, at 4:41 AM, Jeremy Selan wrote:
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: 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" <b...@...>
toggle quoted message
Show quoted text
On 23/01/2011, at 4:41 AM, Jeremy Selan wrote:
|
|
|
|
Jeremy Selan <jeremy...@...>
LGTM, committed.
toggle quoted message
Show quoted text
Thanks! -- Jeremy On Thu, Jan 27, 2011 at 2:52 AM, dbr/Ben <b...@...> wrote:
Oh, |
|
|