[ITK] registration - memory concerns

[Matias Montroull]

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:
>>
>>
>>    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
>>>
>>
>>
>> _______________________________________________
>> 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/b8e3dea9/attachment.html>