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: [email protected]
[mailto:[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], 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
--
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
