[Insight-developers] Re: integrating the new algorithms for existing filters in ITK

[Richard Beare]

Hi,

I think it will be highly variable with image size, since cache
performance tends to be such a major factor.

I'll revisit the reconstruction filter to try and produce some numbers.

On 12/12/06, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> Hi Richard,
>
> I recall that Jim have posted comments related to the padding.
>
> Could you give us an indication of what is the magnitude of
> RAM penalty versus the gain in computation time ?
>
> Depending on that ratio, it may or may not be worth diverging
> from the current coding practices.
>
>
>    Thanks for any hint,
>
>
>       Luis
>
>
> ---------------------
> Richard Beare wrote:
> > Just a note about the reconstruction filter - there is some ugliness
> > relating to performance experiments in that class that will need to be
> > removed.
> >
> > Those experiments highlight a general problem about how difficult it
> > is to design efficient general pupose boundary conditions. In queue
> > based morphological algorithms a common strategy is to pad the images
> > with a max or min to provide a border. In itk this can be done
> > explicitly or implicitly - explict padding results in a quicker
> > filter, but higher ram usage. Optimization using face calculators is
> > not an option in many cases. Sacrificing a border pixel is also
> > possible to improve performance.
> >
> > The same strategy can also be used in watershed and regional extrema
> > filters.
> >
> > It would be nice if we could establish a few conventions that support
> > these options consistently.
> >
> >
> >
> > On 12/11/06, Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
> >
> >>
> >> Hi Luis,
> >>
> >> The new connected component and morphological reconstruction filters done
> >> by Richard are ready for a long time now, and work very well.
> >>
> >> The reconstruction filters are a lot faster, and much important, are a
> >> lot
> >> more efficient concerning memory usage.
> >>
> >> The connected component is a lot more efficient, gives consecutive
> >> labels,
> >> and is able to label an image containing 255 objects with a 8 bit pixel
> >> type - the current filter nearly always fail in that case. This last
> >> feature let the user decrease the memory usage, which is quite important
> >> for me currently.
> >>
> >> I have put those filters in my ITK tree (not in the nightly test builds
> >> this time :-) ) and all the tests are ok. Can I put those new algorithms
> >> in the cvs repository ?
> >>
> >> Thanks,
> >>
> >> Gaetan
> >>
> >>
> >> --
> >> Gaëtan Lehmann
> >> Biologie du Développement et de la Reproduction
> >> INRA de Jouy-en-Josas (France)
> >> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
> >> http://voxel.jouy.inra.fr
> >>
> >
>