[Insight-users] Silly questions about registration

Luis Ibanez luis.ibanez@kitware.com
Mon, 24 Feb 2003 16:01:04 -0500


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
>