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
