New to OCIO, and viewer processes in Nuke

[Hugh Macdonald]

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

nvizible – VISUAL EFFECTS

hugh.ma...@nvizible.com
+44(0) 207 659 2038
+44(0) 7773 764 708

www.nvizible.com

[dbr/Ben]

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

[Jeremy Selan]

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

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
(init.py vs. menu.py) so knob defaults can be appropriate set on
startup. I'll ping our nuke guru to add further details.

-- Jeremy

[Hugh Macdonald]

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/viewer.py (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():
������������nuke.ViewerProcess.unregister(curname)

��������nuke.ViewerProcess.register(
������������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.

displays:
��DCIP3:
����- !<View> {name: Film, colorspace: p3dci8}
����- !<View> {name: Log, colorspace: lg10}
����- !<View> {name: Raw, colorspace: nc10}
��sRGB:
����- !<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
nvizible � VISUAL EFFECTS

hugh.ma...@nvizible.com
+44(0) 20 3167 3860

+44(0) 7773 764 708

www.nvizible.com

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

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
(init.py vs. menu.py) 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 <dbr....@gmail.com> 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.ma...@nvizible.com> 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
nvizible���VISUAL EFFECTS

[DBR - Ben]

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 <hugh.ma...@nvizible.com> 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/viewer.py (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():

            nuke.ViewerProcess.unregister(curname)

        nuke.ViewerProcess.register(
            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.

displays:
  DCIP3:

    - !<View> {name: Film, colorspace: p3dci8}

    - !<View> {name: Log, colorspace: lg10}

    - !<View> {name: Raw, colorspace: nc10}

  sRGB:

    - !<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
nvizible – VISUAL EFFECTS

hugh.ma...@nvizible.com

+44(0) 20 3167 3860

+44(0) 7773 764 708

www.nvizible.com

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

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
(init.py vs. menu.py) 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 <dbr....@gmail.com> 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.ma...@nvizible.com> 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
nvizible – VISUAL EFFECTS

[Sean Looper]

Addressing Jeremy's comment, at Imageworks, we've split up the share/nuke/ocionuke/viewer.py contents such that the registering of ViewerProcess nodes happens during the init.py evaluation and the Viewer lut default value is set during the menu.py evaluation.  This was done to prevent the error that occurs during batch mode when opening a script that has a Viewer lut set to an unregistered value.  The nuke.knobDefault function must run within the menu.py evaluation for it to work successfully, hence the split.

-sean