[Insight-users] Speed

[Richard Beare]

Have you checked that the results of your C implementation are the
same as the ITK one?

If the default ITK mean filter uses shaped neighbourhoods, which it
might, then they tend to be moderately slow because they need to
update the offset for every voxel in the neighbourhood. This may be
the same for the standard neighbourhoods too. The plus is that they
are dimension independent and can handle edge effects. I've certainly
found that moving big neighbourhoods around, without actually doing
anything, is very slow.

There are a couple of ways of doing means quickly, which I've
contributed. I think the box filter uses the image integral approach,
which builds an intermediate image which needs to have a large pixel
type. This one is actually better if you want to compute lots of
different kernel sizes on the same image. The other way is to do
separable filtering, with each separable filter also being recursive.
There is one of those somewhere too, but I can't remember the name
offhand. When we tested these, the last one was the fastest.

Threading control:

itk::MultiThreader::SetGlobalMaximumNumberOfThreads(1);

or

filter->SetNumberOfThreads( t );

On Thu, Feb 10, 2011 at 8:45 AM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
> I've tried BoxMeanImageFilter (which I note was contributed by Richard
> Beare). Indeed it is much faster, in fact it took just 43 sec for my test
> image - a bit more than twice as fast as my code.  It uses all the CPU
> cores.  It also uses a lot of memory, and when I try a test with an image of
> twice the size (200 frames instead of 100) I'm told "This application has
> requested the Runtime to terminate it in an unusual way."  I think it runs
> out of memory (I have only 4GB in this machine).  I guess each thread is
> requesting a big chunk of memory.
>
> I'm intrigued by the way these ITK filters automatically utilize multiple
> processors, and I'm wondering if there is a way to set the number of threads
> that will be invoked.  No doubt there's an IJ article on this topic ..
>