AW: [Insight-users] image orientation and registration, current status? : STATUS UPDATE

[Thees, Sebastian]

Hello Luis,

regarding point 3): on which object of the regeistration framework do I have to set the ->UseImageDirectionOn() flag ?

I tried the optimizer (VersorRigid3DTransform), the orientedImages, the metric (MattesMutualInformationImageToImageMetric) and the registration (MultiResolutionImageRegistrationMethod) but none of them offerd a ->UseImageDirectionOn() member function.

My system config is:
winXP SP2, visual studio 2006, itk cvs-ceckout (3 Feb 2008) and cmake 2.4 patch 7.
In the cmake config the ITK_USE_ORIENTED_IMAGE_DIRECTION option is set to ON by default.

perfoming a grep for "UseImageDirection" on the source directory gives me: 
itkBSplineInterpolateImageFunction.h
itkGradientImageFilter.h
itkGradientRecursiveGaussianImageFilter.h
itkOrientImageFilter.h
itkCentralDifferenceImageFunction.h
itkOptBSplineInterpolateImageFunction.h

so I guess the use of image directions is configured, however I dont know how to set the flag within the registration framework - can you give me another hint ?

best regards and thanks in advance
Sebastian




-----Ursprüngliche Nachricht-----
Von: insight-users-bounces+sebastian.thees=medizin.uni-leipzig.de at itk.org im Auftrag von Luis Ibanez
Gesendet: Fr 01.02.2008 21:31
An: rbrooks at cyberus.ca
Cc: insight-users at itk.org
Betreff: Re: [Insight-users] image orientation and registration, current status? : STATUS UPDATE
 


Just to clarify on the status of this problem:


1) Today: itkImage accepts, and carries Direction
    but *does not* take it into account when
    converting between indexes and physical points.


2) Today: itkOrientedImage accepts, and carries
    Direction *and* takes it into account when
    converting between indexes and physical points.


3) Today: Computation of derivatives *by default*
    do not take image direction into account. BUT,
    if you turn the following CMake option ON:

        ITK_USE_ORIENTED_IMAGE_DIRECTION

    Then they will offer the option of

          UseImageDirectionOn / Off

    *and* if you use them on itkOrientedImages
    then they will compute the derivatives by
    taking orientation into account.


4) The comments regarding the inconsistency of
    the API are justified, and we can simply say
    "shame on use" because we failed to retain
    image direction into the image when we removed
    the default affine transform that was originally
    mapping from indexes to points in the very early
    stage of the project.


5) Image registration of oriented images can be done
    correctly today in ITK by doing:

     A) Turn  "ITK_USE_ORIENTED_IMAGE_DIRECTION"   ON
     B) Using itkOrientedImage instead of itkImage

             ...It is not ideal...
             ...It is not pretty...

    But it is the compromise we reached when trying to
    fix the bug and at the same time maintain backward
    compatibility.


6) Registration of oriented images is tested Nightly
    in all machines that have the above CMake flag
    turned on. (e.g. Zion, Redwall).



7) This is the behavior that we are planning to
    ship with ITK 3.6.


8) If there is enough support from the users community,
    it will be great to fix this the right way in ITK 4.0.

    [That means that some level of backward compatibility
     may need to be sacrificed in the interest of removing
     the current misleading/inconsistent API]




   Regards,


       Luis



--------------------
Rupert Brooks wrote:
> Yes the OrientedImage derivative problem is troublesome.
> 
> If your images are small enough, and your transformation is simple
> enough, the easiest way around it is to use an optimizer that does not
> need derivatives.  Powell's would probably be my choice.  This
> approach gets slow for any sort of complex problem, unfortunately.
> 
> I wrote an Insight Journal paper on the topic that may interest you,
> with some code.  I use the classes in it on a daily basis, so i am
> quite confident in them.  However, you would have to modify the code
> of your metrics.
> http://insight-journal.org/midas/handle.php?handle=1926/1293
> 
> I've also been poring over the code for the multithreaded/optimized
> metrics (it is now in the Review directory in CVS)  It seems to have a
> general gradient method where the problem probably COULD be corrected.
> (http://hdl.handle.net/1926/566)
> 
> Please understand, i am just reading, not developing those
> multithreaded metrics, so I cannot say for sure if they correct this
> problem or not. Perhaps someone working on that project can advise.
> 
> Cheers,
> Rupert B.
> 
> 
> 
> 
> 
>>Date: Fri, 1 Feb 2008 08:17:34 -0500
>>From: "Bill Lorensen" <bill.lorensen at gmail.com>
>>Subject: Re: [Insight-users] image orientation and registration,
>>       current status ?
>>To: "Stefan Klein" <stefan at isi.uu.nl>
>>Cc: insight-users at itk.org
>>Message-ID:
>>       <4db4735c0802010517pc6f45bdw7506c29200b1d64d at mail.gmail.com>
>>Content-Type: text/plain; charset="iso-8859-1"
>>
>>The gradient problem is being corrected for itkOrientedImage. See:
>>http://public.kitware.com/Bug/view.php?id=5081
>>
>>If you need to take into account orientation, you should use
>>itkOrientedImage. Another option is to use itkImage and reorient the series
>>with itkOrientImageFilter so that both series have the same orientation.
>>
>>Bill
> 
> 
_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users