Re: New to OCIO, and viewer processes in Nuke

DBR - Ben <dbr....@...>

Oh, agreed, re-registering the None process is wrong - I didn't put too much thought into this when writing the function, as I didn't need it at the time. Fork away \o/

On 3 August 2011 18:37, Hugh Macdonald <> wrote:
Hi Jeremy and Ben,

I have no issue with removing the default Nuke "None". Right now, it's not being removed, due to this bit of code in share/nuke/ocionuke/ (lines 21-29)

I'm going to fork the repository, and I'll put in a pull request for removing this. I just wasn't sure what people's thoughts on this were already.

    elif also_remove == "all":
        # Unregister all processes, but retain the useful "None" option
        f or curname in nuke.ViewerProcess.registeredNames():
            name = "None",
            call = nuke.nodes.ViewerProcess_None,
            args = ())

My other query, then, would be whether it's possible to re-add a single None viewerProcess in a situation where there are multiple displays and views. In spi-vfx/config.ocio, they are currently defined like this.

    - !<View> {name: Film, colorspace: p3dci8}
    - !<View> {name: Log, colorspace: lg10}
    - !<View> {name: Raw, colorspace: nc10}
    - !<View> {name: Film, colorspace: srgb8}
    - !& lt;View> {name: Log, colorspace: lg10}
    - !<View> {name: Raw, colorspace: nc10}
active_displays: [sRGB, DCIP3]
active_views: [Film, Log, Raw]

This is then doubling up on the Log and Raw LUTs, which aren't actually any different between displays.

Hugh Macdonald
+44(0) 20 3167 3860

+44(0) 7773 764 708

On 03/08/11 18:09, Jeremy Selan wrote:
The other issue is that the nuke-default ocio config is intended to
work in other applications other than nuke.  And many of  these other
apps dont automatically include a 'none' option by default, the same
way Nuke does.

Do you have concerns about removing the default Nuke 'None' option?
As ben mentions, register_viewers() should be removing all of the
original options.

Alternatively, as a compromise we could place the None option at the
bottom of the list.  Thus, while it would be duplicated in your case
at least the second copy wouldn't be getting in the way of the real

I should also note that at Imageworks, while we of course use
OCIODisplay for our viewer, we dont rely on the public
register_viewers() call to register the nodes.  I forget the exact
reason but it relates to splitting up the registration into two parts
( vs. so knob defaults can be appropriate set on
startup.  I'll ping our nuke guru to add further details.

-- Jeremy

On Wed, Aug 3, 2011 at 9:29 AM, dbr/Ben <db...@...> wrote:
The ocionuke.viewer.register_viewers() should have an argument which will
removal all viewer processes, including the default "none" proc (it's no
different to any other, just applies a no op node)
Sent from my iPad
On 03/08/2011, at 11:32, Hugh Macdonald <hugh....@...> wrote:

Hi all,
New OCIO user here... Just playing around with it to see how it'll fit into
our colour pipeline. Primarily playing with the Nuke side of things so far.
One small thing that's cropped up is how, when using the nuke-default
config, there are two "None" items in the viewer process drop-down.
I'm thinking that None probably should still be left in the menu in
ocionuke.viewer.register_viewers(), and the config files should just not
re-define a None. I'm thinking that the nuke-default config file should
maybe reflect this

As I'm quite new to OCIO, I didn't want to start forking and making a pull
request for this kind of change, so I thought I'd bring it up on here first.
Hugh Macdonald
+44(0) 207 659 2038
+44(0) 7773 764 708

Join to automatically receive all group messages.