Malcolm Humphreys <malcolmh...@...>
It all looks great other than the ocio_viewer as I would need to disable this for our install.
toggle quoted messageShow quoted text
I think the nuke nodes should only be registered as part of the ocio project initialisation.
Viewer gizmo's are normally a per company/project configuration, maybe it would be better to include this as a separate example gizmo for people to copy in to their setup.
On 12/01/2011, at 6:07 AM, Jeremy Selan wrote:
Thanks for the commits!
Look great at first glance. (I'll run it all this afternoon to make
sure it works multi-platform, etc). I like all the nuke cleanup, very
My one concern is I'm not convinced the pre-filled display nodes at
startup are appropriate in menu.py. Your new code is an excellent
example to point folks in the right direction, but it may a bit too
overbearing to actually create instances for the user at startup.
Would you expect the average facility to use the code, as written? Or,
is this just an example which you would expect people to customize?
Perhaps this function should be in a different file, which the user is
encouraged to customize as needed?
You can link into the viewer's gain/gamma (just make an expression to
Viewer1.gain, Viewer1.gamma), but there's no way to prevent nuke from
applying the cc math when the sliders are moved. In the short term
maybe the foundry could expose monitor options to disable the
gain/gamma math? (In the long terms, there's potential to have nuke
directly ship with builtin OCIO color management)
On Tue, Jan 11, 2011 at 4:28 AM, dbr/Ben <dbr....@...> wrote:
I've made a few minor changes, partly to familiarise myself with the
code, partly to say thanks for open-sourcing this extremely useful
First change - there was a hardcoded Nuke path, which meant you
couldn't do "cmake -D Nuke_INSTALL_PATH=/blah". Not sure if there's a
reason this this was hardcoded, but it's a (trivially) nicer than
using the env-variable:
Second a slightly less trivial - to support Python installations that
use --exec-prefix to put arch-specific stuff in a separate directory -
before it would fail to compile, complaining "pyconfig.h was not
found" (I guess it's pretty uncommon to use --exec-prefix, as even
PyQT had/has this issue..)
Tested on CentOS, with the exec-prefix'd Python, and OS X 10.6 with
the default system Python, both worked work fine.
Final two commits are to the init.py and menu.py - automagical loading/
menu'ing of the OCIO nodes, and a first attempt at registering
OCIODisplay nodes as Nuke viewer processes.
It adds one process for every display and every transform (e.g "Film1D
(sRGB)", "Log (sRGB)", "Film1D (P3)", "Log (P3)") - seemed like the
most Nuke'ish solution given the limitations of the viewer
On that subject, I wonder if it's possible to somehow tie the viewer's
exposure/gamma controls to the OCIODIsplay node.. I suspect not
As I said, nothing too exciting.. I'm hoping to integrate OCIO into
the pipeline at work soon, so will almost certainly have more patches/
Oh, I've not signed a CLA yet - these changes seemed trivial enough
for it not to be necessary, but I will do so soon. Let me know if this
is a problem
Anyway, thanks again to everyone involved in this project!
- Ben Dickson