[Insight-users] Silly questions about registration
Blezek, Daniel J (Research)
blezek@crd.ge.com
Tue, 25 Feb 2003 08:37:06 -0500
Luis, Dave,
I'm not sure this is the best way of addressing Dave's concerns. Let's put ourselves in the shoes
of a naive user of Insight. Dave did exactly what I would have done. He said, "Hmm, why waste 4x of
my memory by using floats, I'll just run on unsigned chars, and get the same result. This makes
perfect sense (to me at least).
IMHO, it's OK to be PixelType-Aware, but Dave would have spent an amazing amount of time trying to
figure out why he got different results changing from float to unsigned char for registration. While
I agree that floats _can_ be faster, you can also be killed if you start swapping. If we really want
to catch problems at compile time, shouldn't the registration classes prevent you from instantiating
a non-floating point class? Again, as a naive user, I would think one of the best benefits of ITK is
being able to create an unsigned char version of MI registration if I want, but apparently, that is
not the case. Shouldn't the ITK developer be charged with getting the same results across a range of
datatypes? How hard would it be to make the GradientRecursiveGaussianImageFilter have an output of
float, and do all internal calculations with floats/doubles?
I was a bit put off that the GradientRecursiveGaussianImageFilter requires 10x the image size to do
it's work. That seems really huge. For example, if I have a 512x512x512 CT (268M, fixed) to
register to a 256x256x128 MR image (16M, moving). I'd end up having to convert to float ((268+16) *
2 = 568M), and then the GradientRecursizeGaussianImageFilter would take 10x 32M = 320M, for a grand
total of 888Meg of ram? This would send most systems into swap death very quickly.
Should the registration hierarchy be re-visited and be made type independant? It would be trivial
to make a test that would register two images across a whole range of data types and verify the same
results are obtained.
-dan
--
Daniel Blezek, Ph.D.
blezek@crd.ge.com
Visualization and Computer Vision Lab, Imaging Technologies
GE Global Research Center
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
> Sent: Monday, February 24, 2003 4:01 PM
> To: holmesd3@yahoo.com
> Cc: lng@insightful.com; insight
> Subject: Re: [Insight-users] Silly questions about registration
>
>
>
> Hi David
>
>
> Your experience just hightlight the importance of
> being PixelType-Aware in Medical Image applications.
>
> ITK methods are pixel-type templated but this doesn't
> mean they are type-independent.
>
> On the contrary, ITK imposes a higher responsibility
> on the developer to verify the consequences of his/her
> data-type decisions.
>
> The great advantage is that by doing this type checking
> at compile type, you will be confronted with any potential
> problems early in the development cycle, instead of being
> surprised when you are presenting a final demo of your
> system.
>
> ---
>
> Using a "unsigned char" image as input will not
> result in the same output during registration.
>
> The reason is that the MeanSquaresImageMetric
> computes its derivatives by multiplying the Jacobian
> matrix of the transformation with the gradient of
> the fixed image.
>
> This image gradient is computed with the
> GradientRecursiveGaussianImageFilter which uses the
> type of the input image for storing intermediate
> results. Using an "unsigned char" image as input
> results in a lower quality computation of the
> gradient since the intermediate values are
> systematically truncated.
>
> Poor image gradients lead to poor metric derivatives.
>
> Poor metric derivatives lead to poor updates of the
> position in the parametric space by the optimizer.
>
> Poor updates in the parametric space result in incorrect
> values for the final transform. In your case, it seems
> to simply send the transform in a divergent path.
>
>
>
> The memory savings that you may achieve with the
> PixelType replacement have to be evaluated in the
> context of your application. For example, the
> GradientRecursiveGaussianImageFilter will take
> about 10 times the memory of the input image
> regardless of the input image type.
>
> Your application will not run faster for using
> unsigned char as input. In fact it may even run
> slower. Float types will be managed by the math
> instruction of the processor which are faster
> than math operations on integers. Doing math with
> unsigned chars imposes an extra burden on the
> processor and wastes capacity in data transfer
> in-out the processor.
>
> If speed is a concern, you should rather consider
> taking advantage of the multiresolution framework
> and the transform initializers. These strategies
> will provide a more effective way of reducing
> computational times.
>
>
> Please let us know if you have further questions.
>
>
> Thanks
>
>
> Luis
>
>
> -----------------------------------
>
> David Holmes wrote:
>
> > I am unfortunately still having some trouble with the
> > registration methods. In particular, I am still
> > working with the ImageRegistration1.cxx example. When
> > I run the code as is, it gives the correct output and
> > I am happy. However, when looking and the code and
> > data, I realized that the data is 8-bit data but in
> > the code we are working with floats. In the interest
> > of memory management and speed, I decided to change
> > the typedef from:
> >
> > typedef float PixelType
> >
> > to:
> >
> > typedef unsigned char PixelType
> >
> > Because I left everthing else the same, I assumed that
> > the algorithm would work simply with the unsigned char
> > data. When I ran it, I got:
> >
> > Result =
> > Translation X = -191.882
> > Translation Y = -190.493
> > Iterations = 70
> > Metric value = 13.5914
> >
> > I haven't dug into the ITK code nor have I added an
> > Observer to the optimizer yet. I will do that as a
> > next step, but I figured that someone might have a
> > better idea about why this occurse before I dig more
> > myself.
> >
> > Thanks
> >
> > david
> >
>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-users
>