[Insight-users] DemonsRegistrationFilter memory leak?
Vincent Luboz
Vincent.Luboz at imag.fr
Mon Oct 18 18:20:47 EDT 2004
Hi Luis
Thanks a lot for your help, everything is going much faster now!!
> 1) Try compiling for Release (BTW are you in Windows or Unix ?)
You were right: compiling for Release help a lot!! I'm using Visual .net on
Windows XP, and the program run 10 times faster in its release version!
> 4) Given that your data is CT, I don't think you need to preprocess
> your data with HistogramMatching at all. The natural calibration
> of intensity in CT should be good enough for allowing the two
> images to be registered based on the local Optical Flow computed
> by the Demons algorithm.
Ok, I tried without histogram and it works as good as with it.
Consequently, I deleted it and go straight to the matching.
> Just skip the "Matcher" filters. Note that you can also get rid
> of the "Casters" if you instantiate your readers for using
> Images of pixel type float from the beginning. The Reader will
> cast the image data at reading time. These two changes will remove
> (2X + 2*2X = 6X ) copies of your input images from the memory
> taken by the pipeline. It should help to bring down the
> memory footprint of 1.4Gb that you observed.
Right, I changed that into my code too, and I gain quite a lot in memory!
> Please let us know if you have further questions.
well, I do have one more question:
> 2) Demons doesn't have a multi-resolution option built-in, but
> you can manually set up your program in order to do the
> subsampling, solve the registration in the subsampled images,
> then Super-sample the resulting deformation field in order
> to use it in the next finer grid. All the necessary components
> to do this are already in the toolkit.
I would like to try that multi resolution filter but the results given without
downsampling my images are not that good and I am afraid they would be worst
if I use it.
By the way, how can I improve the results of the demon algorithm?
Indeed, I tried to increase the number of iterations (50, 500 and 5000) but
the displacement field resulting is always increasing and in many place it is
going far beyond the real displacement observed during the experiment. I was
expecting it converged to something stable after a certain number of
iterations, but it doesn't seem to be the case. Do I have to change something
else in my code?
I tried to use a gaussian smoothing (the sigma parameter of the demon
algorithm) of 2, 5 and 10, but still, the algorithm does not converge.
Have you got any hints, please?
Here is my code if it can help you:
// declaration of the types of the images
typedef itk::Image< float, Dimension > FixedAndMovingImageType;
typedef itk::ImageFileReader<FixedAndMovingImageType>
FixedAndMovingImageReaderType;
FixedAndMovingImageReaderType::Pointer fixedImageReader =
FixedAndMovingImageReaderType::New();
FixedAndMovingImageReaderType::Pointer movingImageReader =
FixedAndMovingImageReaderType::New();
fixedImageReader->SetFileName(fixedImageFileName);
movingImageReader->SetFileName(movingImageFileName);
// 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<
FixedAndMovingImageType,
FixedAndMovingImageType,
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(fixedImageReader->GetOutput());
registrationFilter->SetMovingImage(movingImageReader->GetOutput());
// The demons registration filter has two parameters: the number of
// iterations to be performed and the standard deviation of the Gaussian
// smoothing kernel to be applied to the deformation field after each
iteration.
registrationFilter->SetNumberOfIterations( 150 );
registrationFilter->SetStandardDeviations( 10.0 );
// The registration algorithm is triggered by updating the filter. The
// filter output is the computed deformation field.
registrationFilter->Update();
It compiles and works but is still not converging to a stable displacement
field.
Thanks in advance,
Vincent.
previous emails:
> ------------------------
>
> Vincent Luboz wrote:
>
> > 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 !
> >
> >
> >
>
>
>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
-------------------------------------------------
envoyé via Webmail/IMAG !
More information about the Insight-users
mailing list