Hey, Thanks Howard for the tool, it really is pretty comfortable. For the performance discussion, I think it's clear, that it doesn't come for free, but as Holger mentioned, you wouldn't use it to watch a whole sequence real time. I would rather turn it on to evaluate my channels and then turn it back off again. Writing min/max in the metadata could be a good idea, but true for the problem that it only directly works with a read node. I also like the idea of implementing this on the gpu.
Patrick ----- Original Message ----- From: [email protected] To: [email protected] Date: 15.10.2012 02:25:38 Subject: Re: [Nuke-users] Normalize Viewer > cool, makes sense. > > Marty > > On 15 October 2012 12:44, Jonathan Egstad <[email protected]> wrote: > >> That only works if the Viewer knows its directly connected to a Read node. >> For instance the metadata stream could be used for the min/max storage. >> >> However if there's any processing nodes in between it and the Read, it >> must assume the color data has been manipulated and the min/max is invalid. >> >> I suppose Nuke could try to figure out if an Iop is only doing a linear >> remapping, but that's an awful lot of special case stuff just to handle >> min/max... >> >> -jonathan >> >> Sent from my iPhone >> >> On Oct 14, 2012, at 3:27 PM, Marten Blumen <[email protected]> wrote: >> >> Can a min/man then be written out with a render pass? Sounds like Nuke >> aint going to get faster, and with a min/max pre-pass you could do it very >> quickly. feature request for OpenEXR 2.1 ;) >> >> On 15 October 2012 11:14, Jonathan Egstad <[email protected]> wrote: >> >>> 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 [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 [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
