[ITK] registration - memory concerns
Matias Montroull
matimontg at gmail.com
Wed Nov 18 13:21:12 EST 2015
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:
>>>>>
>>>>>
>>>>> 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/20151118/9bcc5a63/attachment.html>
More information about the Community
mailing list