[ITK] registration - memory concerns

[Luigi Riba]

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:


   1. I read two grayscale 16 bit .mhd images. To read them I define the
   IOPixelTyep as unsigned short;
   2. I cast them to the "operational" type called PixelType as float
   3. 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:
>>
>>    1. I read a pair of uint16 images;
>>    2. I cast them to float pixel type via the CastImageFilter;
>>    3. 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20151116/48cedc48/attachment-0001.html>