|
Jeremy Selan <jeremy...@...>
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
toggle quoted message
Show quoted text
On Wed, Aug 3, 2011 at 9:29 AM, dbr/Ben <dbr....@...> 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...@...> 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
hugh.ma...@...
+44(0) 207 659 2038
+44(0) 7773 764 708
www.nvizible.com
|
|
|
Hugh Macdonald <hugh.ma...@...>
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.
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 <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
nvizible���VISUAL EFFECTS
hugh.ma...@...
+44(0) 207 659 2038
+44(0) 7773 764 708
www.nvizible.com
|
|
|
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/
toggle quoted message
Show quoted text
On 3 August 2011 18:37, Hugh Macdonald <hugh.ma...@...> 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.
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 <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
nvizible – VISUAL EFFECTS
hugh.ma...@...
+44(0) 207 659 2038
+44(0) 7773 764 708
www.nvizible.com
|
|
|
Sean Looper <sean....@...>
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
toggle quoted message
Show quoted text
On Wed, Aug 3, 2011 at 10:09 AM, Jeremy Selan <jeremy...@...> 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....@...> 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...@...> 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
>
> hugh.ma...@...
> +44(0) 207 659 2038
> +44(0) 7773 764 708
>
> www.nvizible.com
>
|
|
|
