> So instead of creating one big tile per row (and using chucks of it per > pixel) I assume this means that a new Tile is created for every pixel in the > row. My question is how and when is this faster to do this, under what > conditions?
Well if you needed a different sized input filter kernel at each pixel you'd have to request a different sized Tile for each pixel. That's pretty expensive though so I usually request an input Tile that's the max size of the largest filter (if you know that info...) and stretches all the way across the image. This way you can do the Tile caching once per output row. > > The way I was looking at doing this was to just access the out row passed to > the engine() to check each pixel value (to see if I need to do the filtering) > and therefore avoiding creating the Tile at all if not necessary. But I > assume that this is only worthwhile if I went down the route of creating a > tile per pixel rather than how I have it right now using a tile per row. So > really I'm coming back to the question of when using a lots of smaller tiles > per row is faster than the one large tile per row as mentioned in the docs. > I was hoping someone would just tell me so I can be lazy rather than testing > it out ;) > > Cheers, > Steve > > Jonathan Egstad wrote: >> >> 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 >> > > > -- > 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
