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

[Gaetan Lehmann]

concerning that specific case, the image can be padded without problem:  
that's still a huge improvement concerning memory usage.
In my implementation - the current ITK one - the indexes are put in a  
std::set. I can say now that it was not a good choice, and some big images  
can't be processed on my 2GB computer, whereas your filter work just nice.

Gaetan

On Tue, 12 Dec 2006 02:02:00 +0100, Richard Beare  
<richard.beare at gmail.com> wrote:

> 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
>> >>
>> >
>>



-- 
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