[Insight-users] DemonsRegistrationFilter memory leak?
Luis Ibanez
luis.ibanez at kitware.com
Wed Sep 29 16:04:03 EDT 2004
Hi Vincent,
Thanks for the additional details.
1) Try compiling for Release (BTW are you in Windows or Unix ?)
In UNIX this will add automaticall a -O3 to the gcc compling
options. In Windows you *still* have to make sure that when
you open your project with Visual Studio, you explicitly
select to build for "Release".
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.
3) The number of Histogram points are *totally unrelated* to the
Demons method itself. Demons uses a DENSE deformation field,
meaning that it computes a displacement vector *per pixel*.
It is not like FEM or BSplines where you have a coarse grid
overlaid on top of the image.
Even for your unsigned short data you could go with something
simple as 100 histogram points.
Please read the section in the ITK Software Guide that describes
the Demons algorithm. Lydia Ng made a detailed account of the
method and its practical use. You will find this in Section 8.13
in pdf-page 323 of
http://www.itk.org/ItkSoftwareGuide.pdf
As you will see from this chapter, the reason for using the
Histogram matching filters is that Demons is based on the
concept of "Optical Flow" and therefore it has the underlying
assumption that both images have similar distributions of
intensities. This assumption usually doesn't hold for modalities
such as MRI, and therefore a compensation for intensities was
depicted in the examples of the Software Guide.
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.
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.
Please let us know if you have further questions.
Thanks
Luis
------------------------
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 !
>
>
>
More information about the Insight-users
mailing list