Re: [Nuke-users] HSV in OCIOColorSpace node.

[Deke Kincaid]

Sure, I don't see why not.  As long as it can be done via a lut, cdl,
matrix or power function, then you can do it in ocio.

You can read more about ocio config file syntax here:
http://opencolorio.org/userguide/config_syntax.html
ᐧ

--
Deke Kincaid
Media & Entertainment OEM Development Manager
The Foundry
Skype: dekekincaid
Tel: (310) 399 4555 - Mobile: (310) 883 4313
Web: www.thefoundry.co.uk
Email: d...@thefoundry.co.uk

On Thu, Sep 3, 2015 at 8:27 PM, Mads Lund  wrote:

> Hey guys.
>
> I am not too much into the OCIO landscape beyond the build-in profiles.
> Is it possible to make a OCIO config that would allow Linear to HSV
> convertion in the OCIO Colorspace node?
>
> ___
> Nuke-users mailing list
> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Re: [Nuke-users] python expressions locking up the gui

[Howard Jones]

There is a bug reported where I have a simple bit of python which causes 
slowdown on some scripts. The foundry have found the problem though last I 
heard it was not an easy fix. 

I expect you are seeing something similar. Would be worth sending it in and 
mentioning the above. I don't have a bug id to hand. 

But even if you move a node python code can get run which I believe was a 
request though somewhat ott in my view. 

Howard

> On 3 Sep 2015, at 2:42 pm, Mike Frank  wrote:
> 
> Given that you are dealing with a proprietary environment, its anybody's 
> guess whether or not the code is worth while to run.  Most of the time, there 
> is a smarter way that could require refactoring the code base.
> 
> I will say this though, in Nuke 8 they added some dopesheet functionality for 
> time based nodes that requires some compute time.  If the code runs 
> nuke.suspendPathProcessing() its possible you could see a performance 
> increase.
> 
>> On Aug 26, 2015 11:22 AM, "Elvis Au"  wrote:
>> Hey all -
>> 
>> On particularly large nuke scripts, I'm seeing the scripts lock up for a few 
>> seconds before regaining interactivity in the gui. 
>> Digging into it, I found that we have a lot of python code (embedded in tcl 
>> eval code in knobs) which all seem to have to execute any time I make any 
>> update (add/remove a node, change a knob, attach/disconnect a noodle, etc)  
>> And on larger scripts, because there's more of this code that has to be run 
>> through so the lag feels worse.  I can see the expressions fly past if I 
>> have the script editor open and when the it's done printing out, the script 
>> becomes responsive again.
>> 
>> In a test, we removed the python expressions and everything is zippy again.  
>> But this seems excessive that all this code is triggered all the time when 
>> any change is made, upstream or downstream. Is there a rhyme or reason to 
>> this? Has anyone seen this before? Any insights?
>> 
>> Also I'm 8.0v6/linux.
>> 
>> thanks!
>> Elvis
>> 
>> 
>> ___
>> Nuke-users mailing list
>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> ___
> Nuke-users mailing list
> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Re: [Nuke-users] python expressions locking up the gui

[Mike Frank]

Given that you are dealing with a proprietary environment, its anybody's
guess whether or not the code is worth while to run.  Most of the time,
there is a smarter way that could require refactoring the code base.

I will say this though, in Nuke 8 they added some dopesheet functionality
for time based nodes that requires some compute time.  If the code runs
nuke.suspendPathProcessing() its possible you could see a performance
increase.
On Aug 26, 2015 11:22 AM, "Elvis Au"  wrote:

> Hey all -
>
> On particularly large nuke scripts, I'm seeing the scripts lock up for a
> few seconds before regaining interactivity in the gui.
> Digging into it, I found that we have a lot of python code (embedded in
> tcl eval code in knobs) which all seem to have to execute any time I make
> any update (add/remove a node, change a knob, attach/disconnect a noodle,
> etc)  And on larger scripts, because there's more of this code that has to
> be run through so the lag feels worse.  I can see the expressions fly past
> if I have the script editor open and when the it's done printing out, the
> script becomes responsive again.
>
> In a test, we removed the python expressions and everything is zippy
> again.  But this seems excessive that all this code is triggered all the
> time when any change is made, upstream or downstream. Is there a rhyme or
> reason to this? Has anyone seen this before? Any insights?
>
> Also I'm 8.0v6/linux.
>
> thanks!
> Elvis
>
>
> ___
> Nuke-users mailing list
> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users