OCIO CDL Transform bug [NUKE] not applying via cmd line

[throb]

I am working on our output processing and we have a 3dl for display and a ccc per shot.
I can use the ccc in the script no problem.
However, when I try to create all this procedurally via python, the ccc does not take.

example :
import nuke
check = nuke.nodes.CheckerBoard()
cdl = nuke.nodes.OCIOCDLTransform()
cdl['read_from_file'].setValue(True)
cdl['file'].setValue(cdlFile)
write = nuke.nodes.Write(file = outputFile)
write['file_type'].setValue('jpeg')
write['colorspace'].setValue('sRGB')
write['_jpeg_sub_sampling'].setValue('4:4:4')
write['_jpeg_quality'].setValue('1')

write.setInput(0,cdl)
cdl.setInput(0,check)

nuke.execute(write,1,1)

I can load this script into nuke and yes the ccc is transforming the image properly.
However, via python only (using nuke -t) this does not apply the ccc.

additionally, when i set the
cdl['read_from_file'].setValue(True)
i get this error on stdout :
Traceback (most recent call last):
File "", line 1, in
File "c:/Program Files/Nuke6.3v7/plugins\ocionuke\cdl.py", line 104, in
   class SelectCCCIDPanel(nukescripts.PythonPanel):
AttributeError: 'module' object has no attribute 'PythonPanel'

Please advise to the best way of dealing with this issue.

[jeremyselan]

Thanks for the report. Adding @slooper

[throb]

cheers.
i am on win7x64 btw in case it matters.

robert nederhorst | vfx | http://throb.net | 3106210103

On Wed, Jul 11, 2012 at 11:22 AM, Jeremy Selan <
reply@reply.github.com

wrote:

Thanks for the report. Adding @slooper

---

Reply to this email directly or view it on GitHub:
#277 (comment)

[throb]

here is the full python script I use for this:
http://pastebin.com/m3yi8pnL
with my cmd line being :

"c:\Program Files\Nuke6.3v7\Nuke6.3.exe" -t z:\job\after_earth\common\nuke\python\shot_to_jpg.py Z:/job/after_earth/shots/ra/ra035_010/plates/images/RA035_010_BS1_4K_V02/4096x2160/RA035_010_BS1_4K_V02.%04d.exr 1001 1003

[slooper]

I can confirm this issue using 6.3v8 and the latest OCIO build. The error I get is this:

[11:33.01] ERROR: OCIOCDLTransform1: Error loading CDL xml. Source file not specified.

The script works fine interactively.

[throb]

ok I did more digging on this...
the node code when the nuke -t creates the node is such :
OCIOCDLTransform {
read_from_file true
file z:/job/after_earth/shots/ra/ra035_010/lut/ra035_010.ccc
name OCIOCDLTransform1
}

however, if i load that script and immediately save it from the gui i get this :
OCIOCDLTransform {
slope {1.245569944 1.258419991 1.303040028}
offset {0.02236999944 0.02236999944 0.02236999944}
power {0.9728000164 0.9728000164 0.9728000164}
read_from_file true
file z:/job/after_earth/shots/ra/ra035_010/lut/ra035_010.ccc
cccid RA035_010_BS1_4K_V02
name OCIOCDLTransform1
xpos -381
ypos 76
}

the actual reading of the file never happens. there is some kind of manual process that needs to happen and that manual process needs to be removed so that we can access this data easily with nerd badass-ness.

the workaround would be some py code that helps me read the xml data and passes it to the nuke node. that would get me rolling on my pipeline now while the nodes are fixed for future software revs

[slooper]

In the source code, there's a function loadCDLFromFile() that doesn't
appear to be getting called. It's probably because the "file" or
"read_from_file" knobs do not have the "KNOB_ALWAYS_CHANGED" flag set. This
prevents the knob_changed() callback from executing when a knob value is
changed programatically. That doesn't quite explain why the python code
works interactively, but it's possible that Nuke is more strict about when
to execute knob_changed() while in terminal mode.

Either way, I'm suspicious of the various places that loadCDLFromFile is
called and the logic used to decide when to call it. I'll do my best to
take a look at this issue this week.

-sean

On Wed, Jul 11, 2012 at 5:48 PM, Robert Nederhorst <
reply@reply.github.com

wrote:

ok I did more digging on this...
the node code when the nuke -t creates the node is such :
OCIOCDLTransform {
read_from_file true
file z:/job/after_earth/shots/ra/ra035_010/lut/ra035_010.ccc
name OCIOCDLTransform1
}

however, if i load that script and immediately save it from the gui i get
this :
OCIOCDLTransform {
slope {1.245569944 1.258419991 1.303040028}
offset {0.02236999944 0.02236999944 0.02236999944}
power {0.9728000164 0.9728000164 0.9728000164}
read_from_file true
file z:/job/after_earth/shots/ra/ra035_010/lut/ra035_010.ccc
cccid RA035_010_BS1_4K_V02
name OCIOCDLTransform1
xpos -381
ypos 76
}

the actual reading of the file never happens. there is some kind of
manual process that needs to happen and that manual process needs to be
removed so that we can access this data easily with nerd badass-ness.

the workaround would be some py code that helps me read the xml data and
passes it to the nuke node. that would get me rolling on my pipeline now
while the nodes are fixed for future software revs

---

Reply to this email directly or view it on GitHub:
#277 (comment)

[iangodin]

We are also hitting this bug (no attribute 'PythonPanel') when rendering on the command-line (i.e. render farm). Any work around for this?

[throb]

The nuke devs have also not found this bug. I am prepping a script to send
them to illustrate the problem.

robert nederhorst | vfx | http://throb.net | 3106210103

On Mon, Oct 15, 2012 at 1:23 PM, iangodin notifications@github.com wrote:

We are also hitting this bug (no attribute 'PythonPanel') when rendering
on the command-line (i.e. render farm). Any work around for this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/277#issuecomment-9460132.

[dbr]

There's two problems here:

1. Workaround/solution to the PythonPanel added as pull-request OCIOCDLTransform fixes #280 - for temp workaround, you could replace your ocionuke/cdl.py file with the one here

   I'm not sure why this error didn't happen sooner - the ocionuke.cdl module should only be imported when you click one of the buttons (thus are inherently in GUI mode) - are you importing the module in an init.py script somewhere, maybe?

2. The CDL file not being loaded in command line mode.. As @slooper says, there's something weird with how loadCDLFromFile is being called.. The function seems to get called several times (if you shove a print statement in), but doesn't seem to do anything..

   I've played around with a few other ways of doing this, but none seemed to work yet. Will try again tomorrow, and hopefully add to the pull-request...

the workaround would be some py code that helps me read the xml data and passes it to the nuke node. that would get me rolling on my pipeline now while the nodes are fixed for future software revs

Rather late response, but: the ocionuke.cdl module contains the code for this (until it's moved into the core of OCIO/PyOpenColorIO)

Not tested, but something like this should be close:

# Read .ccc file as text, parse it
ccc_contents = open("/path/to/grades.ccc").read()
transforms = ocionuke.cdl._xml_to_cdltransforms(ccc_contents)

if len(transforms) > 1:
     # If using .ccc files containing multiple grades..
     raise ValueError(
         "There were multiple ColorCorrections in this .ccc file. "
         "Erroring as I'm not sure how or if you want to select the correct one")

else:
    # Make nodes
    check = nuke.nodes.CheckerBoard()
    cdlnode = nuke.nodes.OCIOCDLTransform(inputs = [check])

    # transform[0] is the only grade found in the .ccc file, apply it to cdlnode
    ocio.cdl._cdltransform_to_node(cdl = transforms[0], node = cdlnode)