Feature request is logged as Feature 31692 Patrick
----- Original Message ----- From: [email protected] To: [email protected] Date: 15.10.2012 10:58:34 Subject: Re: Re: [Nuke-users] Normalize Viewer > 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 _______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
