[ITK] registration - memory concerns
Luigi Riba
ribaluigi at gmail.com
Thu Nov 19 03:47:52 EST 2015
Dear all,
thanks for the continuous support.
I am gonna try with the BinShrinkImageFilter.
By the way, I guess that I am overlooking something in double to float code
conversion. In fact, I have made this change on the ITK ImageRegistration1
example obtaining the same memory results.
I am on Windows 7, 64 bit, Visual Studio Express 12 (2013), ITK built in
release mode with MT flags. I will be pleased if you could give a look at
this piece of code.
I have attached at this mail:
ImageRegistration1Double: exactly the same as ImageRegistration1, with
MemoryProbe added;
ImageRegistration1Float: MemoryProbe added and changed double to float in
registration blocks;
BrainProton.....png a pair of test images;
Results....png a screenshot of the results in both cases.
Have a nice day,
Luigi
2015-11-18 22:50 GMT+01:00 Matt McCormick <matt.mccormick at kitware.com>:
> Hi Luigi,
>
> It may be prudent to downsample the images using something like the
> BinShrinkImageFilter. Often, the full-resolution is overkill for the
> registration task.
>
> HTH,
> Matt
>
> On Wed, Nov 18, 2015 at 1:21 PM, Matias Montroull <matimontg at gmail.com>
> wrote:
> > Luigi, I assume you are workimg on release mode right?
> > Would you be able to send the cpp file that you are compiling to test?
> >
> > Matias
> >
> > On Nov 18, 2015 7:53 AM, "Luigi Riba" <ribaluigi at gmail.com> wrote:
> >>
> >> Dear all,
> >>
> >> I have tried your suggestions and I have simplified my code.
> >> Unfortunately, I still have some issues:
> >>
> >> 1. I cannot read the two images as unsigned short. If I do like this,
> >> VisualStudio compiler returns:
> >> Error 2 error C2440: 'initializing' : cannot convert from
> >> 'itk::Concept::Detail::UniqueType_bool<false>' to
> >> 'itk::Concept::Detail::UniqueType_bool<true>'
> >> f:\libs\itk\modules\core\common\include\itkConceptChecking.h 796 1
> affine3d
> >>
> >> 2. I have decided to read the images directly in float;
> >>
> >> 3. I have set everything to float but I have noticed no memory usage
> >> differences between the "dobule" and "float" code. In particular, I have
> >> set:
> >>>
> >>> typedef float InternalComputationValueType;
> >>> typedef itk::AffineTransform< InternalComputationValueType, Dimension>
> >>> TransformType;
> >>> typedef
> >>>
> itk::RegularStepGradientDescentOptimizerv4<InternalComputationValueType>
> >>> OptimizerType;
> >>> typedef itk::MeanSquaresImageToImageMetricv4<ImageType, ImageType,
> >>> ImageType, InternalComputationValueType> MetricType;
> >>> typedef itk::ImageRegistrationMethodv4<ImageType, ImageType,
> >>> TransformType> RegistrationType;
> >>> typedef float CoordinateType;
> >>> typedef itk::LinearInterpolateImageFunction<ImageType, CoordinateType>
> >>> InterpolationType;
> >>
> >>
> >> RECAP:
> >> 1. I would like to reduce the memory usage of my registration code. In
> >> fact, I work with unsigned short, i.e. 16 bit grayscale images, ~1Gb
> each
> >> and memory usage gets high pretty soon (750MB images -> ~30GB total
> memory
> >> usage)
> >> 2. It has been suggested to set the algorithm to work with float instead
> >> of double;
> >> 3. How can I accomplish point 2.?
> >> 4. Is point 2. the only viable solution in order to reduce memory usage?
> >> 5 Is there a way to have a finer monitoring of memory usage. For the
> >> moment I am using itkMemoryProbe which just gives me the total amount of
> >> used memory.
> >>
> >> Thank you for your kind support,
> >> Luigi
> >>
> >>
> >> 2015-11-16 16:55 GMT+01:00 Luigi Riba <ribaluigi at gmail.com>:
> >>>
> >>> Dear Dženan and Matias,
> >>>
> >>> thank you very much for the help.
> >>>
> >>> I'll test your suggestion and I'll post back the results for the
> >>> community.
> >>>
> >>> Best,
> >>>
> >>> Luigi
> >>>
> >>> 2015-11-16 16:53 GMT+01:00 Matias Montroull <matimontg at gmail.com>:
> >>>>
> >>>> That was my assumption Luigi
> >>>>
> >>>> El lun., 16 de nov. de 2015 a la(s) 12:30 p. m., Dženan Zukić
> >>>> <dzenanz at gmail.com> escribió:
> >>>>>
> >>>>> I believe Matias thought that your original pixel type was signed
> >>>>> short.
> >>>>>
> >>>>> So just use the images you read as unsigned short (set them as input
> to
> >>>>> the registration), and don't make another copy of the images by
> casting them
> >>>>> to float.
> >>>>>
> >>>>> HTH
> >>>>>
> >>>>> On Mon, Nov 16, 2015 at 10:17 AM, Luigi Riba <ribaluigi at gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> Dear Matias,
> >>>>>>
> >>>>>> thank you very much for your quick reply.
> >>>>>>
> >>>>>> Unfortunately, I didn't have time yet to test it. Anyhow, could you
> >>>>>> please tell me the rationale behind it?
> >>>>>>
> >>>>>> In my code:
> >>>>>>
> >>>>>> I read two grayscale 16 bit .mhd images. To read them I define the
> >>>>>> IOPixelTyep as unsigned short;
> >>>>>> I cast them to the "operational" type called PixelType as float
> >>>>>> I define all the registration objects templated on float.
> >>>>>>
> >>>>>> Why should I cast my images to PixelType == signed short?
> >>>>>>
> >>>>>> Thanks in advance for the support,
> >>>>>> Luigi
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2015-11-10 15:45 GMT+01:00 Matias Montroull <matimontg at gmail.com>:
> >>>>>>>
> >>>>>>> try this:
> >>>>>>> typedef signed short PixelType;
> >>>>>>>
> >>>>>>>
> >>>>>>> El mar., 10 de nov. de 2015 a la(s) 11:36 a. m., Luigi Riba
> >>>>>>> <ribaluigi at gmail.com> escribió:
> >>>>>>>>
> >>>>>>>> Dear Matt,
> >>>>>>>>
> >>>>>>>> I have tried following your suggestion but, unfortunately, it
> didn't
> >>>>>>>> work out.
> >>>>>>>>
> >>>>>>>> In particular:
> >>>>>>>>
> >>>>>>>> I read a pair of uint16 images;
> >>>>>>>> I cast them to float pixel type via the CastImageFilter;
> >>>>>>>> I change the TInternalComputationValueType for the metric, the
> >>>>>>>> optimizer, the transform and the registration doing something
> like:
> >>>>>>>>>
> >>>>>>>>> const unsigned int Dimension = 3;
> >>>>>>>>>
> >>>>>>>>> typedef float PixelType;
> >>>>>>>>>
> >>>>>>>>> typedef unsigned short IOPixelType;
> >>>>>>>>>
> >>>>>>>>> typedef itk::Image<IOPixelType, Dimension> IOImageType;
> >>>>>>>>>
> >>>>>>>>> typedef itk::Image<PixelType, Dimension> ImageType;
> >>>>>>>>>
> >>>>>>>>> typedef itk::AffineTransform<float, Dimension > TransformType;
> >>>>>>>>>
> >>>>>>>>> typedef itk::RegularStepGradientDescentOptimizerv4<float>
> >>>>>>>>> OptimizerType;
> >>>>>>>>>
> >>>>>>>>> typedef itk::MeanSquaresImageToImageMetricv4<ImageType,
> >>>>>>>>> ImageType,ImageType,float> MetricType;
> >>>>>>>>>
> >>>>>>>>> typedef itk::ImageRegistrationMethodv4<ImageType, ImageType,
> >>>>>>>>> TransformType> RegistrationType;
> >>>>>>>>>
> >>>>>>>>> typedef itk::ResampleImageFilter<IOImageType, IOImageType,
> >>>>>>>>> float,float> ResampleFilterType;
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I have put one memory probe before the registration procedure and
> >>>>>>>> one afterwards of it. In the "double" case and in the "float"
> case I've seen
> >>>>>>>> the same memory consumption.
> >>>>>>>>
> >>>>>>>> Am I missing something? Are there other things I should change in
> my
> >>>>>>>> code?
> >>>>>>>>
> >>>>>>>> Thanks again for the support,
> >>>>>>>> Luigi
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2015-11-09 17:23 GMT+01:00 Matt McCormick
> >>>>>>>> <matt.mccormick at kitware.com>:
> >>>>>>>>>
> >>>>>>>>> Hi Luigi,
> >>>>>>>>>
> >>>>>>>>> The type of optimizer should not have too large of an impact on
> >>>>>>>>> memory
> >>>>>>>>> consumption. Using a gradient-free optimizer may help slightly,
> >>>>>>>>> but
> >>>>>>>>> try changing the pixel type of the input images or, if possible,
> >>>>>>>>> the
> >>>>>>>>> parameter type of the transformation, from double to float.
> >>>>>>>>>
> >>>>>>>>> HTH,
> >>>>>>>>> Matt
> >>>>>>>>>
> >>>>>>>>> On Mon, Nov 9, 2015 at 10:24 AM, Luigi Riba <ribaluigi at gmail.com
> >
> >>>>>>>>> wrote:
> >>>>>>>>> > Dear all,
> >>>>>>>>> >
> >>>>>>>>> > I am registering a couple of volumes with ITK 4 on windows 7 64
> >>>>>>>>> > bit.
> >>>>>>>>> >
> >>>>>>>>> > I wrote a code based on the affine transformation, with the
> mean
> >>>>>>>>> > square
> >>>>>>>>> > error metric and the RegularStepGradientDescentOptimizerv4.
> >>>>>>>>> > Unfortunately,
> >>>>>>>>> > the memory usage is pretty high.
> >>>>>>>>> >
> >>>>>>>>> > I have checked memory consumption with the itkMemoryProbe and,
> >>>>>>>>> > after looking
> >>>>>>>>> > around on previous mailing list messages I have decided to try
> >>>>>>>>> > with a
> >>>>>>>>> > gradient free optimizer like the Nelder-Mead one.
> >>>>>>>>> >
> >>>>>>>>> > So I have rewrote the code using the AmoebaOptimizerV4 and I
> have
> >>>>>>>>> > continued
> >>>>>>>>> > monitoring the memory consumption via MemoryProbe.
> Unfortunately,
> >>>>>>>>> > it seems
> >>>>>>>>> > that nothing has changed. Is this working as expected? If this
> is
> >>>>>>>>> > the case,
> >>>>>>>>> > do you have any suggestion to gave me in order to reduce the
> >>>>>>>>> > memory
> >>>>>>>>> > consumption of the code?
> >>>>>>>>> >
> >>>>>>>>> > Thanks in advance for the help.
> >>>>>>>>> >
> >>>>>>>>> > Best,
> >>>>>>>>> >
> >>>>>>>>> > Luigi
> >>>>>>>>> >
> >>>>>>>>> > _______________________________________________
> >>>>>>>>> > Community mailing list
> >>>>>>>>> > Community at itk.org
> >>>>>>>>> > http://public.kitware.com/mailman/listinfo/community
> >>>>>>>>> >
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Community mailing list
> >>>>>>>> Community at itk.org
> >>>>>>>> http://public.kitware.com/mailman/listinfo/community
> >>>>>>>
> >>>>>>> --
> >>>>>>> Matias
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Community mailing list
> >>>>>> Community at itk.org
> >>>>>> http://public.kitware.com/mailman/listinfo/community
> >>>>>>
> >>>>>
> >>>> --
> >>>> Matias
> >>>
> >>>
> >>
> >
> > _______________________________________________
> > Community mailing list
> > Community at itk.org
> > http://public.kitware.com/mailman/listinfo/community
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20151119/45f1fe84/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BrainProtonDensitySliceBorder20.png
Type: image/png
Size: 17925 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/community/attachments/20151119/45f1fe84/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BrainProtonDensitySliceShifted13x17y.png
Type: image/png
Size: 17887 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/community/attachments/20151119/45f1fe84/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ImageRegistration1Float.zip
Type: application/zip
Size: 10235 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/community/attachments/20151119/45f1fe84/attachment-0002.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ImageRegistration1Double.zip
Type: application/zip
Size: 10241 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/community/attachments/20151119/45f1fe84/attachment-0003.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: results.png
Type: image/png
Size: 65260 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/community/attachments/20151119/45f1fe84/attachment-0005.png>
More information about the Community
mailing list