On Jun 6, 2012, at 10:12 AM, Steven Booth wrote: > Are you doing this in an engine thread? If so, the center pixel has already > been given to you in the 'row' passed to engine. That would, by far, be the > fastest way to get the center pixel, I would think.
That's only if the tile is being gotten from input0 of the Iop and you've already done a get() into a row, or you're using a PixelIop - Stephen didn't specify. If it's from a secondary input or it's a raw Iop you have to get the entire thing yourself. > And, if you use the [z][y][x] format (which is, as Johathan observes, the > fastest), be sure you use the 'tile.clampx'/'tile.clampy' to properly > validate your coordinates, or you may crash Nuke. > > Steve > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Jonathan > Egstad > Sent: Wednesday, June 06, 2012 10:05 AM > To: Nuke plug-in development discussion > Subject: Re: [Nuke-dev] Fastest way of accessing a single pixel in an IOP > > Well, you definitely don't want to use Tile::at() as that does bounds > checking. > > Using tile[z][y][x] is relatively fast except that it's doing the pointer > multiplies at each pixel - it's fastest to do organize the loop by channel > (z) and initialize a pointer to the start of each line (y) and iterate across > pre-incrementing the pointer. > > Not sure what a tile-per-pixel means relative to a tile-per-row - got a > reference to that quote in the docs? > > -jonathan > > On Jun 6, 2012, at 5:00 AM, Stephen Newbold wrote: > >> Hi, >> >> I have a IOP that uses a largish tile to do some filtering. I'm looking to >> do some basic optimisation to speed things up by skipping doing the >> filtering on any back pixel. What's the most efficient way of checking the >> value of the current pixel, which is also the centre value of my tile? >> >> My tile is the size of my entire row plus the width/height of the filter. >> I'm iterating through each X value in the row, should I just directly access >> the pixel from the tile with tile[z][y][x]. Or is there a more efficient >> way of doing this? >> >> Also, in the docs there is talk of maybe creating a tile per pixel is faster >> than a tile per row. Is there a clear distinction for when one is faster >> than the other (ie. does tile size determine this)? >> >> 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], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > 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], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
