Hi guys, the is_zero() function is not the same as checking that every pixel is zero, instead is compares the channel's buffer pointer with a list of zero buffer pointers, stored internally. A channel is set to a zero buffer if erase() is called (see documentation for erase()). This is obviously a lot faster than looping every pixel in the row, and should be used if possible.
Hope that helps Tom On Tue, Jun 12, 2012 at 10:11 AM, Stephen Newbold < [email protected]> wrote: > Thanks Steve, that seems to clear things up. > > I'm still trying to find the best way of not having to filter craps loads > of dead space. Way I see it I have end up having to check the value of > every pixel in a tile to see if that pixel contributes to the filter so I > guess its really important using the optimal way of doing this regardless > how convoluted the code might end up. > > Fun stuff! > > Cheers, > Steve > > > Steven Booth wrote: > >> Steve, >> >> The Blocky code *is* a bit strange in that they allocate a Tile, and then >> do not explicitly use it for anything, which is pretty confusing. Since >> the Tile is requested over the same ChannelSet as the Row passed to the >> 'engine' method, the call to the Tile guarantees that the region specified >> in the Tile call has been requested from the up-stream node, and will >> therefore be stored in the cache. All subsequent accesses of pixels within >> this region will, then, be obtained from the cache, and not input0. That >> means the Row call will be faster, yes (as will any functions that access >> this data). >> >> As regards the .is_zero() method, I we don't have the code for it >> (perhaps someone from The Foundry might chime in here), so there is no way >> to know if it's implementation is faster than a manual 'for' loop, checking >> for zero pixels. My gut tells me it's more a convenience function, and not >> there for speed. I'm thinking that you won't see a huge difference in >> performance between custom code and 'is_zero'. >> >> Hope that helps. >> >> Steve >> >> >> -----Original Message----- >> From: >> nuke-dev-bounces@support.**thefoundry.co.uk<[email protected]>[mailto: >> nuke-dev-bounces@**support.thefoundry.co.uk<[email protected]>] >> On Behalf Of Stephen Newbold >> Sent: Monday, June 11, 2012 10:48 AM >> To: Nuke plug-in development discussion >> Subject: [Nuke-dev] More tile/row questions >> >> Hi, >> >> I'm working my way through all the docs and sample scripts trying to get >> my head around a few things. In the Blocky.cpp code a tile is created and >> then never mentioned again. I row is created that is the same width as the >> tile, can I assume from this that it is faster to access this particular >> region as it already contained within the tile? Is this only the case if >> the row is the same width as the tile or could I create a row that was >> smaller than the confines of the tile? >> >> Is there a simple explanation why it is better to grab a row this way >> (after defining a tile) than simply just creating the row without the tile. >> Is it down to multiple threads being able to access the tile or something? >> >> Next question is regarding dead space in an image. I see row.is_zero() >> can be used and also an interest.is_zero(). Are these just as fast as each >> other? If I want to check my tile for all empty pixels in order to ignore >> huge areas of black space, is this the best way to go about it? >> >> Cheers, >> Steve >> >> -- >> Stephen Newbold >> Compositing Lead - Film >> MPC >> 127 Wardour Street >> Soho, London, W1F 0NL >> Main - + 44 (0) 20 7434 3100 >> www.moving-picture.com >> >> ______________________________**_________________ >> Nuke-dev mailing list >> [email protected].**co.uk <[email protected]>, >> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-dev<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev> >> (CONFIDENTIALITY NOTICE: The information contained in this email may be >> confidential and/or privileged. This email is intended to be reviewed by >> only the individual or organization named above. If you are not the >> intended recipient, or an authorized representative of the intended >> recipient, you are hereby notified that any review, dissemination or >> copying of this email, or the information contained herein is strictly >> prohibited. If you have received this communication in error, please notify >> the sender by return email and delete this email from your system. Thank >> You.) >> >> ______________________________**_________________ >> Nuke-dev mailing list >> [email protected].**co.uk <[email protected]>, >> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-dev<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev> >> >> > > > -- > Stephen Newbold > Compositing Lead - Film > MPC > 127 Wardour Street > Soho, London, W1F 0NL > Main - + 44 (0) 20 7434 3100 > www.moving-picture.com > > ______________________________**_________________ > Nuke-dev mailing list > [email protected].**co.uk <[email protected]>, > http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> > http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-dev<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev> > -- Tom Ward, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
