[Insight-users] RGB 2D image registration

[Darren Weber]

What is the optimal way to handle RGB images for registration?  I need to
read more of the software guide for a better understanding, but I have some
time pressure and any advice from the list would be really useful right now.

"If you decide to interpret RGB images as simply three independent channels
then you should
rather use the itk::Vector type as pixel type. In this way, you will have
access to the set of
operations that are defined in Vector spaces. The current implementation of
the RGBPixel in
ITK presumes that RGB color images are intended to be used in applications
where a formal
interpretation of color is desired, therefore only the operations that are
valid in a color space are
available in the RGBPixel class."  (ITK Software Guide, p. 44.)

Should we use itk::Vector as the pixel type for image registration of RGB
images?  Is the alternative to split each RGB channel and use a registration
for each channel, then somehow "average" the registration transformations or
select the transform with the best metric outcome?

I have a stack of 2D microscopy images.  Each image is a 2D TIFF with RGB
pixels (ImageJ indicates the data is 32 bits/pix, so it's probably 4 x 8 bit
RGBA, but the A-alpha channel is a waste of space in this data).  For
example,
ftp://ftp.buckinstitute.org/dweber/section_0445_w1.tif
ftp://ftp.buckinstitute.org/dweber/section_0446_w1.tif

I general, the registation should use an affine transformation, maybe a
multi-resolution process.

BTW, using the example code for ImageRegistration1.cxx, I get the following
warnings from the image reader:
TIFFReadDirectory: Warning,
worm1_autoalign_tifResCorrect/section_0447_w1.tif: wrong data type 7 for
"RichTIFFIPTC"; tag ignored.
TIFFReadDirectory: Warning,
worm1_autoalign_tifResCorrect/section_0447_w1.tif: unknown field with tag
34665 (0x8769) encountered.

TIA,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090630/0e051752/attachment.htm>