[ITK] registration - memory concerns
Luigi Riba
ribaluigi at gmail.com
Thu Nov 19 16:13:01 EST 2015
Hello Matias,
thanks for the reply and for the tests you have done.
Unfortunately, it seems to be pretty hard to reduce memory consumption.
Anyhow, I have partially avoided the problem following Matt suggestion
about binning and deciding to work on a sub region of the volume itself.
Still it would be interesting to me to better understand memory usage of
itk.
By the way, the kind of volumes I am working with are at least 500x500x500
pixels (16bit) or more.
Have a nice day,
Luigi
2015-11-19 17:51 GMT+01:00 Matias Montroull <matimontg at gmail.com>:
> 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/c3ac0896/attachment-0001.html>
More information about the Community
mailing list