[Insight-users] RGB 2D image registration

Wed Jul 1 14:37:54 EDT 2009

Hi Darren,

One of the first things to do when working on Image Registration
and/or Image Segmentation is to give up on the Illusion of the "Optimal".

Anybody who claims to have the "Best" method for any kind of image
processing is clearly new to this field,

...or has not been paying attention...

There is no "Best"
There is no "Optimal"

Remove from your image processing vocabulary the words:

   * Always
   * Never
   * Best
   * Optimal

They only lead to confusion...

I know it is hard, since the many Irreproducible Journals and Conference
in our field keep trying to sell us the Snake-Oil Illusion of the "Best",
and
researchers lose their objectivity quite rapidly when they see the
opportunity
of planting their name on some of the intellectual real state by getting
a method to be know by their last name.

Both segmentation and registration are Ill-posed problems.
They don't have "right" solutions.

Image analysis is an "Engineering" problem,
not a Mathematical one.

(despite the fact that we profusely use mathematical equations
in order to give an air of "scientific-look" to the many irreproducible
papers that are published every year).

What you are looking for, is a method that is "good enough", at
a "reasonable price" for your requirements of "development time"
and "computation time".

             Now that we are back to reality,
             let's talk about your problem

0) In principle you can perform registration between RGB images
    by simply writing an ImageMetric class that will evaluate what
    *YOU* consider to be an important match between RGB images.

1) You will also need an Interpolator class that works with RGB images.
    Currently you could use the Vector Interpolators.

2) With an RGB-compatible ImageMetric and Interpolator, you can
    reuse all the other components of the existing image registration
    framework :   Transform, Optimizers... etc

3) We don't have an RGB Image Metric currently.
    It may take you a couple of days to a week to write one properly.

4) If you are in a hurry, I would suggest to convert your RGB image
    to a Luminance image, and do standard image registration of
    scalar images as described in the ITK Software Guide.

5)  Reading your TIFF images in GIMP and decomposing their
     channels into independent layers shows that there is no Alpha
     channel available, only R,G,B.

     It seems that the G layer doesn't contain much information.
     R and B seem to be the most informative ones.

6) As an alternative to (4), You could use the ImageAdaptors or the
    IndexSelection image filter for extracting the R or the B channel
    from your images and use them as input for a scalar-based the
     registration and any of the many examples in ITK.

7) Affine is a good starting point, but the images of the cell (s?)
    will need some local deformation in order to be aligned.
    You will have to consider using BSplines or Demons.

Finally, the warning that you get when reading the TIFF images
is independent of the image registration framework, and should
be addressed independently as a TIFFImageIO problem.

Please feel free to open a bug report for this issue in the MANTIS
bug tracker:

http://public.kitware.com/Bug/my_view_page.php

However,
please note that the same warning is shown by GIMP
when opening the images. (you may want to mention
this in the bug report)

       Regards,

             Luis

----------------------------------------------------------------------------------------------------------
On Wed, Jul 1, 2009 at 1:54 AM, Darren Weber
<darren.weber.lists at gmail.com>wrote:

>
> 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
>
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090701/48ac25e8/attachment-0001.htm>