[Insight-users] DemonsRegistrationFilter memory leak?

[Vincent Luboz]

Hi Luis

Thanks a lot for your answer!

Few answers to your questions and then more questions:   ;-)

> 1) Did you compiled your code for "Release" ?
>     Just that could give you up to a factor of
>     10X in execution time.

Right, I didn't think about that and I am actually compling in Debug... I am 
going to change that.

> 2) When you attempt to use Demons in 3D image
>     you usually want to do this in a multi-resolution
>     framework, especially if you exect to find large
>     deformations.

So you mean I should use a filter to downsample the 3D images? or is there an 
option in the itkDemonRegistration to take this into account?

> 3) The number of matchnig points that you set up
>     in the histogram (10,000) seems to be excesive.
>     Is there a particular reason why you decided to
>     go that far ?
>     What is the pixel type of your images  ?

The pixel type of my image is unsigne short.
I used 10000 points in the histogram since I thought that this value was the 
number of points (placed regularly on a grid) used to compute the elastic 
transformation from one image to another.
Is it wrong?

You say that I could get rid of the histogram part.

So you mean, instead of having
registrationFilter->SetMovingImage(matcher->GetOutput());
in the following code, I would have:
registrationFilter->SetMovingImage(movingImageCaster->GetOutput());
where matcher is the histogram filter and movingImageCaster is the moving 
image after being cast.

// In the DemonsRegistrationFilter, the deformation field is
// represented as an image whose pixels are floating point vectors.
typedef itk::Vector< float, Dimension >    VectorPixelType;
typedef itk::Image<VectorPixelType, Dimension> DeformationFieldType;
typedef itk::DemonsRegistrationFilter<
              InternalImageType,
              InternalImageType,
              DeformationFieldType>   RegistrationFilterType;

RegistrationFilterType::Pointer registrationFilter = 
RegistrationFilterType::New();

// The input fixed image is simply the output of the fixed image casting
// filter.  The input moving image is the output of the histogram matching 
filter.
registrationFilter->SetFixedImage(fixedImageCaster->GetOutput());
registrationFilter->SetMovingImage(matcher->GetOutput());

is it correct?

Again, thanks a lot for your help

Best regards,

Vincent.


Quoting Luis Ibanez <luis.ibanez at kitware.com>:
> 
> Hi Vincent,
> 
> Memory leaks should in principle show up in our daily
> Purify builds. Nothing seems to be reported for the
> DemonsRegistration filter, as you can see from the most
> recent Purify build:
> 
> http://www.itk.org/Testing/Sites/moxel2.crd/WinNT-VC++60/20040927-0500-
Nightly/DynamicAnalysis.html
> 
> You probably can speed up a lot your registration
> by considering the following issues:
> 
> 1) Did you compiled your code for "Release" ?
>     Just that could give you up to a factor of
>     10X in execution time.
> 
> 2) When you attempt to use Demons in 3D image
>     you usually want to do this in a multi-resolution
>     framework, especially if you exect to find large
>     deformations.
> 
> 3) The number of matchnig points that you set up
>     in the histogram (10,000) seems to be excesive.
>     Is there a particular reason why you decided to
>     go that far ?
>     What is the pixel type of your images  ?
> 
> 4) When you are using CT scans you usually don't
>     need the HistogramIntensity correction at all.
>     Intensigy correction is mostly oriented to MRI
>     images that tend to have arbitrary scalings in
>     intensity.  CT on the other hand are usually
>     in Hounsfield units. That should result in
>     similar tissues having similar intensities in
>     both images.  I would suggest you to skip the
>     intensity correction between the two CT images
>     unless you are using images that are not calibrated
>     in Hounsfield units.
> 
> 
> The memory usage of 1.4Gb seems excesive, but in practice
> it depends of how many things you put together in the pipeline.
> Note that the deformation field for that image size will have
> an image of Vectors with double or float component type, that
> alone will take about 230Mb...
> 
> 
>    Please let us now more details of what you are doing.
> 
> 
>      Regards,
> 
> 
>        Luis
> 
> 
> ---------------------------
> Vincent.Luboz at imag.fr wrote:
> 
> > Hi itk users
> > 
> > I'm using the itkHistogramMatchingImageFilter combined with the 
> > itkDemonsRegistrationFilter to match 2 sets of 3D CT scans. The first one
> is 
> > an object and the second one is the same object but slightly deformed (it
> is 
> > an elastic deformation induced by a load on the object).
> > I used the example given in the itkDemonsRegistrationFilterTest file to
> used 
> > this matching algorithm and my program is a copy of it (except the variable
> 
> > values).
> > The transformation resulting from the matching seems fine but it takes a 
> > really long time to compute. For example it took 24 hours for matching my 2
> 
> > data sets (both of them have a size of 20Mo and 512x512x36 in pixel size)
> with 
> > 10000 points for the histogram, only 20 iterations for the demon algorithm
> and 
> > a sigma of 5 (to smooth the result since I only asked for 20 iterations).
> > Is it normal that it takes that long?
> > I was thinking that it may be due to a memory leak of the demon algorithm 
> > since when I run my program, it starts by reading the 2 data sets, so the 
> > memory increases by 40 Mo but them it keeps increasing until reaching a
> memory 
> > usage of 1.4Go!!
> > Is it normal? What can I do to avoid that or to get the result faster?
> > 
> > Thanks in advance for your help,
> > 
> > Vincent.
> > 
> > 
> > -------------------------------------------------
> > envoyé via Webmail/IMAG !
> > 
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users at itk.org
> > http://www.itk.org/mailman/listinfo/insight-users
> > 
> > 
> 
> 
> 
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 




-------------------------------------------------
envoyé via Webmail/IMAG !