<br>Hi Darren,<br><br><br>One of the first things to do when working on Image Registration <br>and/or Image Segmentation is to give up on the Illusion of the &quot;Optimal&quot;.<br><br><br>Anybody who claims to have the &quot;Best&quot; method for any kind of image <br>
processing is clearly new to this field, <br><br>...or has not been paying attention...<br><br><br>There is no &quot;Best&quot;<br>There is no &quot;Optimal&quot;<br><br><br>Remove from your image processing vocabulary the words:<br>
<br>   * Always<br>   * Never<br>   * Best<br>   * Optimal<br><br>They only lead to confusion...<br><br><br><br>I know it is hard, since the many Irreproducible Journals and Conference<br>
in our field keep trying to sell us the Snake-Oil Illusion of the &quot;Best&quot;, and<br>
researchers lose their objectivity quite rapidly when they see the opportunity<br>
of planting their name on some of the intellectual real state by getting<br>
a method to be know by their last name.<br>
<br>
<br><br>Both segmentation and registration are Ill-posed problems.<br>They don&#39;t have &quot;right&quot; solutions.<br><br><br>Image analysis is an &quot;Engineering&quot; problem,<br>not a Mathematical one.<br><br>(despite the fact that we profusely use mathematical equations<br>
in order to give an air of &quot;scientific-look&quot; to the many irreproducible<br>papers that are published every year).<br><br><br>What you are looking for, is a method that is &quot;good enough&quot;, at <br>a &quot;reasonable price&quot; for your requirements of &quot;development time&quot;<br>
and &quot;computation time&quot;.<br><br><br>             Now that we are back to reality, <br>             let&#39;s talk about your problem<br><br><br><br>0) In principle you can perform registration between RGB images<br>
    by simply writing an ImageMetric class that will evaluate what<br>    *YOU* consider to be an important match between RGB images.<br><br><br>1) You will also need an Interpolator class that works with RGB images.<br>    Currently you could use the Vector Interpolators.<br>
<br><br>2) With an RGB-compatible ImageMetric and Interpolator, you can <br>    reuse all the other components of the existing image registration<br>    framework :   Transform, Optimizers... etc<br><br><br>3) We don&#39;t have an RGB Image Metric currently.<br>
    It may take you a couple of days to a week to write one properly.<br><br><br>4) If you are in a hurry, I would suggest to convert your RGB image<br>    to a Luminance image, and do standard image registration of <br>    scalar images as described in the ITK Software Guide.<br>
<br><br>5)  Reading your TIFF images in GIMP and decomposing their <br>     channels into independent layers shows that there is no Alpha<br>     channel available, only R,G,B.<br><br>     It seems that the G layer doesn&#39;t contain much information.<br>
     R and B seem to be the most informative ones.<br><br><br>6) As an alternative to (4), You could use the ImageAdaptors or the <br>    IndexSelection image filter for extracting the R or the B channel <br>    from your images and use them as input for a scalar-based the<br>
     registration and any of the many examples in ITK.<br><br><br>7) Affine is a good starting point, but the images of the cell (s?)<br>    will need some local deformation in order to be aligned.<br>    You will have to consider using BSplines or Demons.<br>
<br><br>Finally, the warning that you get when reading the TIFF images <br>is independent of the image registration framework, and should<br>be addressed independently as a TIFFImageIO problem.<br><br>Please feel free to open a bug report for this issue in the MANTIS<br>
bug tracker:<br><br><a href="http://public.kitware.com/Bug/my_view_page.php">http://public.kitware.com/Bug/my_view_page.php</a><br><br>However, <br>please note that the same warning is shown by GIMP<br>when opening the images. (you may want to mention <br>
this in the bug report)<br><br><br><br>       Regards,<br><br><br>             Luis<br><br><br>----------------------------------------------------------------------------------------------------------<br><div class="gmail_quote">
On Wed, Jul 1, 2009 at 1:54 AM, Darren Weber <span dir="ltr">&lt;<a href="mailto:darren.weber.lists@gmail.com">darren.weber.lists@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>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.<br>

<br>&quot;If you decide to interpret RGB images as simply three independent channels then you should<br>rather use the itk::Vector type as pixel type. In this way, you will have access to the set of<br>operations that are defined in Vector spaces. The current implementation of the RGBPixel in<br>

ITK presumes that RGB color images are intended to be used in applications where a formal<br>interpretation of color is desired, therefore only the operations that are valid in a color space are<br>available in the RGBPixel class.&quot;  (ITK Software Guide, p. 44.)<br>

<br>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 &quot;average&quot; the registration transformations or select the transform with the best metric outcome?<br>

<br>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&#39;s probably 4 x 8 bit RGBA, but the A-alpha channel is a waste of space in this data).  For example,<br>

<a href="ftp://ftp.buckinstitute.org/dweber/section_0445_w1.tif" target="_blank">ftp://ftp.buckinstitute.org/dweber/section_0445_w1.tif</a><br><a href="ftp://ftp.buckinstitute.org/dweber/section_0446_w1.tif" target="_blank">ftp://ftp.buckinstitute.org/dweber/section_0446_w1.tif</a><br>

<br>I general, the registation should use an affine transformation, maybe a multi-resolution process.<br><br>BTW, using the example code for ImageRegistration1.cxx, I get the following warnings from the image reader:<br>
TIFFReadDirectory: Warning, worm1_autoalign_tifResCorrect/section_0447_w1.tif: wrong data type 7 for &quot;RichTIFFIPTC&quot;; tag ignored.<br>
TIFFReadDirectory: Warning, worm1_autoalign_tifResCorrect/section_0447_w1.tif: unknown field with tag 34665 (0x8769) encountered.<br><br>TIA,<br><font color="#888888">Darren<br><br>
</font><br>_____________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at: <a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br>
<br></blockquote></div><br>