Luis,<br><br>Thanks for the great summary. I agree with everything except point 8. I am confident we can come to a solution in the future that will have the correct behaviour but maintain backward compatibility. Realistically, the results of registration may change, but not dramatically I think.<br>
<br>Bill<br><br><div class="gmail_quote">On Fri, Feb 1, 2008 at 3:31 PM, Luis Ibanez <<a href="mailto:luis.ibanez@kitware.com">luis.ibanez@kitware.com</a>> 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>
<br>
Just to clarify on the status of this problem:<br>
<br>
<br>
1) Today: itkImage accepts, and carries Direction<br>
but *does not* take it into account when<br>
converting between indexes and physical points.<br>
<br>
<br>
2) Today: itkOrientedImage accepts, and carries<br>
Direction *and* takes it into account when<br>
converting between indexes and physical points.<br>
<br>
<br>
3) Today: Computation of derivatives *by default*<br>
do not take image direction into account. BUT,<br>
if you turn the following CMake option ON:<br>
<br>
ITK_USE_ORIENTED_IMAGE_DIRECTION<br>
<br>
Then they will offer the option of<br>
<br>
UseImageDirectionOn / Off<br>
<br>
*and* if you use them on itkOrientedImages<br>
then they will compute the derivatives by<br>
taking orientation into account.<br>
<br>
<br>
4) The comments regarding the inconsistency of<br>
the API are justified, and we can simply say<br>
"shame on use" because we failed to retain<br>
image direction into the image when we removed<br>
the default affine transform that was originally<br>
mapping from indexes to points in the very early<br>
stage of the project.<br>
<br>
<br>
5) Image registration of oriented images can be done<br>
correctly today in ITK by doing:<br>
<br>
A) Turn "ITK_USE_ORIENTED_IMAGE_DIRECTION" ON<br>
B) Using itkOrientedImage instead of itkImage<br>
<br>
...It is not ideal...<br>
...It is not pretty...<br>
<br>
But it is the compromise we reached when trying to<br>
fix the bug and at the same time maintain backward<br>
compatibility.<br>
<br>
<br>
6) Registration of oriented images is tested Nightly<br>
in all machines that have the above CMake flag<br>
turned on. (e.g. Zion, Redwall).<br>
<br>
<br>
<br>
7) This is the behavior that we are planning to<br>
ship with ITK 3.6.<br>
<br>
<br>
8) If there is enough support from the users community,<br>
it will be great to fix this the right way in ITK 4.0.<br>
<br>
[That means that some level of backward compatibility<br>
may need to be sacrificed in the interest of removing<br>
the current misleading/inconsistent API]<br>
<br>
<br>
<br>
<br>
Regards,<br>
<br>
<br>
Luis<br>
<br>
<br>
<br>
--------------------<br>
Rupert Brooks wrote:<br>
> Yes the OrientedImage derivative problem is troublesome.<br>
><br>
> If your images are small enough, and your transformation is simple<br>
> enough, the easiest way around it is to use an optimizer that does not<br>
> need derivatives. Powell's would probably be my choice. This<br>
> approach gets slow for any sort of complex problem, unfortunately.<br>
><br>
> I wrote an Insight Journal paper on the topic that may interest you,<br>
> with some code. I use the classes in it on a daily basis, so i am<br>
> quite confident in them. However, you would have to modify the code<br>
> of your metrics.<br>
> <a href="http://insight-journal.org/midas/handle.php?handle=1926/1293" target="_blank">http://insight-journal.org/midas/handle.php?handle=1926/1293</a><br>
><br>
> I've also been poring over the code for the multithreaded/optimized<br>
> metrics (it is now in the Review directory in CVS) It seems to have a<br>
> general gradient method where the problem probably COULD be corrected.<br>
> (<a href="http://hdl.handle.net/1926/566" target="_blank">http://hdl.handle.net/1926/566</a>)<br>
><br>
> Please understand, i am just reading, not developing those<br>
> multithreaded metrics, so I cannot say for sure if they correct this<br>
> problem or not. Perhaps someone working on that project can advise.<br>
><br>
> Cheers,<br>
> Rupert B.<br>
><br>
><br>
><br>
><br>
><br>
>>Date: Fri, 1 Feb 2008 08:17:34 -0500<br>
>>From: "Bill Lorensen" <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>><br>
>>Subject: Re: [Insight-users] image orientation and registration,<br>
>> current status ?<br>
>>To: "Stefan Klein" <<a href="mailto:stefan@isi.uu.nl">stefan@isi.uu.nl</a>><br>
>>Cc: <a href="mailto:insight-users@itk.org">insight-users@itk.org</a><br>
>>Message-ID:<br>
>> <<a href="mailto:4db4735c0802010517pc6f45bdw7506c29200b1d64d@mail.gmail.com">4db4735c0802010517pc6f45bdw7506c29200b1d64d@mail.gmail.com</a>><br>
>>Content-Type: text/plain; charset="iso-8859-1"<br>
>><br>
>>The gradient problem is being corrected for itkOrientedImage. See:<br>
>><a href="http://public.kitware.com/Bug/view.php?id=5081" target="_blank">http://public.kitware.com/Bug/view.php?id=5081</a><br>
>><br>
>>If you need to take into account orientation, you should use<br>
>>itkOrientedImage. Another option is to use itkImage and reorient the series<br>
>>with itkOrientImageFilter so that both series have the same orientation.<br>
>><br>
>>Bill<br>
><br>
><br>
_______________________________________________<br>
Insight-users mailing list<br>
<a href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br>
<a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br>
</blockquote></div><br>