Yeah, Ivan’s right that it breaks Nuke’s scanline request system by bottlenecking the tree at the Average node until all upstream scanlines have been calculated. However, the benefits of having a "set it and forget it" solution in the situation we were dealing with made it worth it. Plus, you can always precomp or cache immediately after your average operation.
-Nathan From: Ivan Busquets Sent: Thursday, September 01, 2011 11:36 AM To: Nuke Python discussion Subject: Re: [Nuke-python] quickly average non-zero pixels? I'm sure The Foundry have their reasons for not adding one before now though, and I'd be curious to hear them. It could always be something as simple as no one really asking for it, though I suspect that's not the case. Can't say for sure, but I assume one of the reasons could be that this is the kind of tool that would make a script slow. As you said you're doing in your plugin, you need to lock a thread first, read the whole input to average all pixels together, and then use the results as you wish. This breaks the nice scanline-by-scanline processing you get out of most tools, so at that point in the tree the whole image would need to be calculated before you see any further updates. I imagine the cases where you really need this to happen "live" are not that many, and usually analysing the whole sequence with a CurveTool ends up paying off cause you're hit once with the analysis process, but don't get the time penalty of it happening "live" in your script. However, I agree it would be nice to have a "live" sampling tool by default, even if it comes with a big note about its implications in performance. As a workaround, I usually use the same technique Hugh mentioned above. Make sure your image has an alpha relevant to the pixels you want to analyse, blur the hell out of it, and unpremult. Just my 2 cents Ivan On Thu, Sep 1, 2011 at 8:30 AM, Nathan Rusch <[email protected]> wrote: Lev Kolobov wrote: I'm actually surprised too, because you can drag select area in viewer and will give you an average instantly. How does it work? Why the average tool is so complicated to do. The way I ended up doing it involved some work with thread locking and switching between single- and multi-threaded engine calls, but it was still fairly basic to implement. I'm sure The Foundry have their reasons for not adding one before now though, and I'd be curious to hear them. It could always be something as simple as no one really asking for it, though I suspect that's not the case. Oliver Jezequel wrote: doesn't it what the curveTool node is doing already ??? have you tried that ? it return you the average of your ROI in the pict. As far as my plugin goes, I believe it will output the same values as the CurveTool (thanks for reminding me though; I'll test that when I get in this morning). However, instead of outputting them to a knob, they end up in the image channels. The main reason I wrote it is to avoid having to execute a node every time I wanted the values recalculated. We were doing some tests of 2D HDR lighting of facial capture scans and needed a way to dynamically average the different HDR lookup samples to be multiplied against other color data. -Nathan _______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python -------------------------------------------------------------------------------- _______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
