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
