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 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
