Sure...and those programs (Flame, Fusion, etc) use full-frame buffers which are 
massive memory hogs at high-res and take a long time to update if you're doing 
anything complicated.

Like rotating an image 90deg it's just one of those operations which doesn't 
fit well in a scanline architecture.

You can still do them, you just pay a price.

-jonathan

Sent from my iPhone

On Oct 14, 2012, at 2:17 PM, Frank Rueter <[email protected]> wrote:

> True that, but it obviously works in other softwares (which ever way they do 
> it).
> In any case, a speedy normalised view of channels would be appreciated as a 
> native viewer feature.
> 
> I just published Howard's tool:
> http://www.nukepedia.com/python/ui/viewer-input-presets/
> 
> 
> 
> On 10/15/12 5:50 AM, Jonathan Egstad wrote:
>> Hi Frank,
>> 
>> Not to a devil's advocate or anything...but calculating the min/max of an 
>> image means sampling the entire image before a single pixel can be drawn in 
>> the Viewer.  Needless to say this will destroy Nuke's update speed.
>> 
>> As long as that's understood as a side-effect of this feature, then soldier 
>> on.
>> 
>> -jonathan
>> 
>> Sent from my iPhone
>> 
>> On Oct 13, 2012, at 6:22 PM, Frank Rueter <[email protected]> wrote:
>> 
>>> None of those solutions actually produce what we're after though (some of 
>>> your solutions seem to invert the input).
>>> 
>>> We need something that can compresses the input to a 0-1 range by 
>>> offsetting and scaling based on the image's min and max           values 
>>> (so the resulting range is 0-1). You can totally do this with a Grade or 
>>> Expression node and a bit of tcl or python (or the CurveTool if you want to 
>>> pre-compute), but that's not efficient.
>>> 
>>> I reckon this should be a feature built into the viewer for ease-of-use and 
>>> speed.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 14/10/12 1:04 PM, Marten Blumen wrote:
>>>> and this group does all channels rgba,depth,motion using the expressions. 
>>>> should be quite fast as an input process
>>>> 
>>>> set cut_paste_input [stack 0]
>>>> version 7.0 v1b74
>>>> push $cut_paste_input
>>>> Group {
>>>>  name Normalised_channels
>>>>  selected true
>>>>  xpos -526
>>>>  ypos 270
>>>> }
>>>>  Input {
>>>>   inputs 0
>>>>   name Input1
>>>>   xpos -458
>>>>   ypos 189
>>>>  }
>>>>  Expression {
>>>>   expr0 "mantissa (abs(r))"
>>>>   expr1 "mantissa (abs(g))"
>>>>   expr2 "mantissa (abs(b))"
>>>>   channel3 depth
>>>>   expr3 "mantissa (abs(z))"
>>>>   name Normalized_Technical1
>>>>   tile_color 0xb200ffff
>>>>   label rgbz
>>>>   note_font Helvetica
>>>>   xpos -458
>>>>   ypos 229
>>>>  }
>>>>  Expression {
>>>>   channel0 alpha
>>>>   expr0 "mantissa (abs(a))"
>>>>   channel1 {forward.u -forward.v -backward.u forward.u}
>>>>   expr1 "mantissa (abs(u))"
>>>>   channel2 {-forward.u forward.v -backward.u forward.v}
>>>>   expr2 "mantissa (abs(v))"
>>>>   channel3 depth
>>>>   name Normalized_Motion1
>>>>   tile_color 0xb200ffff
>>>>   label "a, motion u & v"
>>>>   note_font Helvetica
>>>>   xpos -458
>>>>   ypos 270
>>>>  }
>>>>  Output {
>>>>   name Output1
>>>>   xpos -458
>>>>   ypos 370
>>>>  }
>>>> end_group
>>>> 
>>>> 
>>>> On 14 October 2012 11:29, Marten Blumen <[email protected]> wrote:
>>>> And one that looks technical or techni-color!
>>>> 
>>>> 
>>>> set cut_paste_input [stack 0]
>>>> version 7.0 v1b74
>>>> push $cut_paste_input
>>>> Expression {
>>>>  expr0 "mantissa (abs(r))"
>>>>  expr1 "mantissa (abs(g))"
>>>>  expr2 "mantissa (abs(b))"
>>>>  channel3 depth
>>>>  expr3 "mantissa (abs(z))"
>>>>  name Normalized_Technical
>>>>  tile_color 0xb200ffff
>>>> 
>>>>  label "Normalized\n"
>>>>  note_font Helvetica
>>>>  selected true
>>>>  xpos -286
>>>>  ypos -49
>>>> 
>>>> }
>>>> 
>>>> 
>>>> On 14 October 2012 10:46, Marten Blumen <[email protected]> wrote:
>>>> This works for rgb & depth. Pop it into the ViewerProcess for normalized 
>>>> viewing. It seems to work with all values, free polygon cube to anyone who 
>>>> breaks it ;) 
>>>> 
>>>> Who knows the expression node; can we just apply the formula to all the 
>>>> present channels?
>>>> 
>>>> 
>>>> set cut_paste_input [stack 0]
>>>> version 7.0 v1b74
>>>> push $cut_paste_input
>>>> Expression {
>>>>  expr0 1/(r+1)/10
>>>>  expr1 1/(g+1)/10
>>>>  expr2 1/(b+1)/10
>>>>  channel3 depth
>>>>  expr3 1/(z+1)/10
>>>>  name RGBDEPTH
>>>>  label "Normalized\n"
>>>>  note_font Helvetica
>>>>  selected true
>>>>  xpos -220
>>>>  ypos 50
>>>> 
>>>> }
>>>> 
>>>> 
>>>> On 14 October 2012 10:24, Marten Blumen <[email protected]> wrote:
>>>> A normalised expression node:
>>>> 
>>>> 
>>>> set cut_paste_input [stack 0]
>>>> version 7.0 v1b74
>>>> push $cut_paste_input
>>>> Expression {
>>>>  expr0 1/(r+1)/10
>>>>  expr1 1/(g+1)/10
>>>>  expr2 1/(b+1)/10
>>>>  name Expression6
>>>>  label "Normalize Me\n"
>>>>  note_font Helvetica
>>>>  selected true
>>>>  xpos -306
>>>>  ypos 83
>>>> 
>>>> }
>>>> 
>>>> 
>>>> On 14 October 2012 09:33, Marten Blumen <[email protected]> wrote:
>>>> + 1 
>>>> 
>>>> as a side note, doesn't SoftClip and Toe nodes do dynamic normalising of 
>>>> the RGB channels?
>>>> 
>>>> set cut_paste_input [stack 0]
>>>> version 7.0 v1b74
>>>> push $cut_paste_input
>>>> SoftClip {
>>>> conversion "logarithmic compress"
>>>> softclip_min 1
>>>> name SoftClip2
>>>> selected true
>>>> xpos -1876
>>>> ypos 1428
>>>> }
>>>> Toe2 {
>>>> name Toe2
>>>> selected true
>>>> xpos -1876
>>>> ypos 1461
>>>> 
>>>> }
>>>> 
>>>> 
>>>> On 13 October 2012 23:51, Patrick Heinen <[email protected]> 
>>>> wrote:
>>>> Yes of course I can use                                                 
>>>> VIEWER_INPUT or a register a viewer process, but that wouldn't make it 
>>>> dynamic either, well maybe with the MinColor Node but that one again 
>>>> doesn't work for deep data... And starting to sample every pixel via 
>>>> python is just horribly slow and you would need to bake it after that 
>>>> again. Plus again the VIEWER_INPUT doesn't work for deep data either...
>>>> It shouldn't be to complicated having one                                  
>>>>                button, that dynamically                                    
>>>>              normalizes what's shown in the Viewer, just as you have it in 
>>>> Fusion.
>>>> 
>>>> I sent in a request, Ticket#2012101310000031
>>>> 
>>>> Regards
>>>> Patrick
>>>> 
>>>> Am 13.10.2012 um 11:42 schrieb Johannes Hezer:
>>>> 
>>>> > +1
>>>> >
>>>> >
>>>> > Am 10/13/12 7:47 AM, schrieb Frank Rueter:
>>>> >> Same. It would indeed be very helpful. Has somebody sent in a request 
>>>> >> yet?
>>>> >>
>>>> >>
>>>> >> On 13/10/12 6:54 AM, Holger Hummel|Celluloid VFX                        
>>>> >>                              wrote:
>>>> >>> yes, you can.
>>>> >>> BUT:
>>>> >>> - it needs manual work: you need to know/find the min/max values. they 
>>>> >>> change from pass to pass, actually in most cases from frame to frame.
>>>> >>> - it's quicker when you can just click on button to toggle this. also 
>>>> >>> because it does not conflict with some other VIWER_INPUT that might be 
>>>> >>> active.
>>>> >>>
>>>> >>> so +1 from me making this a feature request
>>>> >>>
>>>> >>> - Holger
>>>> >>>
>>>> >>>
>>>> >>> jbidwell wrote:
>>>> >>>> You can make a grade and group it, then name it "VIEWER_INPUT". The 
>>>> >>>> viewer will use that grade in the viewer whenever the IP button is 
>>>> >>>> active.
>>>> >>>>
>>>> >>>> - JB
>>>> >>>> ------------------------------------------------------------------------
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> Nuke-users mailing list
>>>> >>>> [email protected], http://forums.thefoundry.co.uk/
>>>> >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>> >>>
>>>> >>
>>>> >> _______________________________________________
>>>> >> Nuke-users mailing list
>>>> >> [email protected], http://forums.thefoundry.co.uk/
>>>> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>> >
>>>> > _______________________________________________
>>>> > Nuke-users mailing list
>>>> > [email protected], http://forums.thefoundry.co.uk/
>>>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>> 
>>>> _______________________________________________
>>>> Nuke-users mailing list
>>>> [email protected], http://forums.thefoundry.co.uk/
>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Nuke-users mailing list
>>>> [email protected], http://forums.thefoundry.co.uk/
>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>> 
>>> _______________________________________________
>>> Nuke-users mailing list
>>> [email protected], http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>> 
>> 
>> _______________________________________________
>> Nuke-users mailing list
>> [email protected], http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> 
> _______________________________________________
> Nuke-users mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Reply via email to