[ITK] registration - memory concerns
Matias Montroull
matimontg at gmail.com
Thu Nov 19 11:51:20 EST 2015
I was testing different aproaches and I always get nothing less than 2800,
how many images does the volume have?
El jue., 19 de nov. de 2015 a la(s) 5:47 a. m., Luigi Riba <
ribaluigi at gmail.com> escribió:
> 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
>> >
>>
>
> --
Matias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20151119/2fef1eca/attachment-0001.html>
More information about the Community
mailing list