[Insight-users] Registering two sturctural studies.
Luis Ibanez
luis.ibanez at kitware.com
Wed Oct 10 15:13:48 EDT 2007
Hi Frank,
If you suspect that the readers are not loading the image direction
information correctly, you can use the itkChangeInformationFilter to
"manually" insert the Direction Cosines into the itk::OrientedImage.
http://www.itk.org/Insight/Doxygen/html/classitk_1_1ChangeInformationImageFilter.html
Please look at the methods.
ChangeDirectionOn();
SetOutputDirection( directionMatrix );
Again: Since your two images were acquired one after another,
in the same scanner, and you only change the acquisition
directtion:
You *dont* need to perform an image registration.
only an image resampling.
and You *dont* need a transform other than the
IdentityTransform in the ResampleImageFilter.
UNLESS the subject has moved between the two acquisitions....or
UNLESS the direction cosines reported by the scanner are bogus.
Note:
The ImageRegistration8.cxx example *does not* use Euler angles.
Versor componets *are not* Euler angles. Versors are the equivalent
of Unit Quaternions.
For details on the concept of Versors you may want to look at the
Tutorials:
http://www.itk.org/CourseWare/Training/QuaternionsI.pdf
http://www.itk.org/CourseWare/Training/QuaternionsII.pdf
Regards,
Luis
-------------------
Frank Ezekiel wrote:
> Luis:
>
> I do have my own code for reading the DCM and position data from
> dicoms. So, if I knew how to initialize a VersorRigid3DTransform using
> a DCM and offset matrix I could presumably bypass the ITK code and just
> compute the transformation.
>
> Is there a way to initialize a VersorRigid3DTransform with a DCM
> and offset matrix rather than with Euler data as is done in the
> ImageRegistration8 example?
>
> Thanks,
>
> Frank
>
>
> At 07:06 AM 10/10/2007, you wrote:
>
>> Hi Frank,
>>
>> One easy way to see if the DCM direction is being read correctly
>> from your Nifti files is to print out the image information just
>> after reading the image.
>>
>> Please add to your code:
>>
>> reader->GetOuptut()->Print( std::cout );
>>
>> after you call
>>
>> reader->Update();
>>
>> and in the console output look for the section on the image
>> direction. You can then verify whether it matches the DCM direction
>> that you were expecting from the Nifti files.
>>
>> The itk::Image *will not* take Direction Cosines into account.
>> Only the itk::OrientedImage will do so.
>>
>>
>>
>> There is an open bug related to the use of itk::OrientedImages
>> in the ITK registration framework, but it refers to the computation
>> of Metric derivatives. This will not affect what you are doing,
>> since you should simply be running the itk::ResampleFilter.
>>
>> You *DO NOT* need to perform a registration, just a resampling.
>>
>> The itk::ResampleImageFilter, when instantiated over
>> itk::OrientedImages will take image orientation into account.
>>
>> The transform that you need to use is the itk::IdentityTransform.
>> This is an explicit ITK class, and it doesn't have any parameters,
>> so there is no need for you to worry about transform initialization.
>>
>>
>> Regards,
>>
>>
>> Luis
>>
>>
>>
>> ---------------------
>> Frank Ezekiel wrote:
>>
>>> Luis:
>>> I'm using 3.30 ITK, and seeing some strange behavior. Using
>>> ImageRegistration8 (as you suggested) as my example, I'm able to read
>>> in a "fixed" and "moving" image, then store the moving image at the
>>> resolution of the fixed.
>>> However, when I try to use the exact same dataset in nifti
>>> format files (which contain the DCM positional data) the same code
>>> fails. (The resulting image is sampled entirely outside the FOV of
>>> the source image)
>>> Is ITK using the DCM and transformation data from the nifti
>>> format version of these data even when I use only itk::Image as the
>>> type? I thought that functionality was limited to itk::OrientedImage.
>>> Any thoughts?
>>> Also, I've still not found the correct code to initialize a
>>> transformation that will align the MovingImage with the FixedImage
>>> (resolution, dimensions, AND spatial orientation)
>>>
>>> Finally, I've seen reports of problems with
>>> itk::OrientedImage. Are there any code samples of how to manually
>>> create a correctly orienting tranformation by reading the DCM values
>>> from the two images, then doing the matrix inversion and
>>> multiplication manually? The notes I saw on itk::OrientedImage
>>> indicated that it wasn't yet fully fixed even in version 3.40.
>>>
>>> Thanks again,
>>> Frank
>>>
>>> At 05:47 PM 10/8/2007, you wrote:
>>>
>>>> Hi Frank,
>>>>
>>>> Since your two images are relating to the same scanner,
>>>> you should be ok by simply using an IdentityTransform:
>>>>
>>>> http://www.itk.org/Insight/Doxygen/html/classitk_1_1IdentityTransform.html
>>>>
>>>>
>>>>
>>>> Note that the itk::IdentityTransform class doesn't take any parameters.
>>>> Simply create one instance of this transform connect it to the
>>>> itk::ResampleImageFilter.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>> Luis
>>>>
>>>>
>>>>
>>>> ------------------------
>>>> Frank Ezekiel wrote:
>>>>
>>>>> Any hints on how to initialize the transform that will be used?
>>>>> finalTransform->SetParameters( finalParameters );
>>>>>
>>>>> How do I set up the transform object to properly do the
>>>>> "difference" between the orientation and translation parameters?
>>>>> Thanks again,
>>>>> Frank
>>>>>
>>>>> At 08:15 AM 10/6/2007, you wrote:
>>>>>
>>>>>> Hi Frank,
>>>>>>
>>>>>> From your description it seems that you only need to resample
>>>>>> image B using the grid of image A.
>>>>>>
>>>>>> That is, you are relying on the fact that both images have been
>>>>>> acquired from the same scanner, and that the image origing and
>>>>>> direction cosines are correct.
>>>>>>
>>>>>> That should work fine.
>>>>>>
>>>>>> Just remember to use the itk::OrientedImage<> instead of the
>>>>>> itk::Image.
>>>>>>
>>>>>> The itk::OrientedImage will take the Direction cosines into
>>>>>> account when it is used by the interpolator of the Resample
>>>>>> ImageFilter.
>>>>>>
>>>>>>
>>>>>> Please read the ITK Software Guide,
>>>>>>
>>>>>> http://www.itk.org/ItkSoftwareGuide.pdf
>>>>>>
>>>>>> in particular Section 6.9.4 "Resample Image Filter" in
>>>>>> pdf-pages 254-448.
>>>>>>
>>>>>> This section describes in detail how to use the ResampleImageFilter.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>> Luis
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------
>>>>>> Frank Ezekiel wrote:
>>>>>>
>>>>>>> Luis:
>>>>>>> Thank you for the initial response. At this point, my
>>>>>>> goal has changed slightly. I'm looking to use ITK to write a
>>>>>>> function that will align MovingImage to FixedImage WITHOUT any
>>>>>>> intensity based registration.
>>>>>>> That is, I want to use ONLY the DCM (direction cosine
>>>>>>> matrix) and coordinate offset data included in a dicom header.
>>>>>>> (The reason is that my FixedImage space is from single
>>>>>>> voxel spectroscopy, so there is inadequate intensity information
>>>>>>> to use a cost function + resampling for alignment.)
>>>>>>> Can ITK do this? It basically just requires computing
>>>>>>> and applying the "difference transformation" between two images
>>>>>>> acquired in the same session.
>>>>>>>
>>>>>>> Thanks again for the help,
>>>>>>> Frank
>>>>>>>
>>>>>>>
>>>>>>> At 07:34 AM 8/5/2007, Luis Ibanez wrote:
>>>>>>>
>>>>>>>> Hi Frank,
>>>>>>>>
>>>>>>>>
>>>>>>>> You may want to start with the example:
>>>>>>>>
>>>>>>>>
>>>>>>>> ImageRegistration8.cxx
>>>>>>>>
>>>>>>>>
>>>>>>>> in the directory:
>>>>>>>>
>>>>>>>>
>>>>>>>> Insight/Examples/Registration
>>>>>>>>
>>>>>>>>
>>>>>>>> This example is described in detail in the
>>>>>>>> ITK Software Guide
>>>>>>>>
>>>>>>>> http://www.itk.org/ItkSoftwareGuide.pdf
>>>>>>>>
>>>>>>>> in the "Image Registration" chapter.
>>>>>>>>
>>>>>>>>
>>>>>>>> We *STRONGLY* recommend you to read the entire chapter
>>>>>>>> before you start playing with the registration. You
>>>>>>>> should also read the Section on image resampling since
>>>>>>>> they are very closely related.
>>>>>>>>
>>>>>>>> Since your images seems to be from the same modality
>>>>>>>> and same patient, you can probably solve this by using
>>>>>>>> the following components:
>>>>>>>>
>>>>>>>> 1) Mean Squares Metric
>>>>>>>> 2) VersorRigid3D Transform
>>>>>>>> 3) Linear Interpolator
>>>>>>>> 4) VersorRigid3DTransformOptimizer
>>>>>>>>
>>>>>>>> Note that, since you are reading this from DICOM,
>>>>>>>> you want to replace the "itk::Image" type in the
>>>>>>>> code with "itk::OrientedImage" type, in order to
>>>>>>>> make sure that the direction cosines of your images
>>>>>>>> are taken into account.
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Examples on how to read DICOM series are available
>>>>>>>> in the directory:
>>>>>>>>
>>>>>>>>
>>>>>>>> Insight/Examples/IO
>>>>>>>>
>>>>>>>> and are described as well in the ITK Software Guide
>>>>>>>> in the Chapter "Reading and Writing Images".
>>>>>>>>
>>>>>>>>
>>>>>>>> Please let us know if you find any problems
>>>>>>>> while setting up your registration code.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>>
>>>>>>>> Luis
>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------
>>>>>>>> Frank Ezekiel wrote:
>>>>>>>>
>>>>>>>>> Hi:
>>>>>>>>> I have multiple MRI acquisitions acquired on Siemens
>>>>>>>>> Medspec 4T and stored in Dicom. I'm looking for the quickest
>>>>>>>>> and easiest way to compute the rotations and translations
>>>>>>>>> needed to align one dataset with the other (assuming no movement).
>>>>>>>>> Could someone please enumerate my options within ITK for
>>>>>>>>> doing this? I really just want a robust readout of angles
>>>>>>>>> and mm translations given Dicom 3.0 files with tags (0020,0032)
>>>>>>>>> and (0020,0037) filled in.
>>>>>>>>> Suggestions?
>>>>>>>>> Thanks mucho,
>>>>>>>>> Frank
>>>>>>>>> _______________________________________________
>>>>>>>>> Insight-users mailing list
>>>>>>>>> Insight-users at itk.org
>>>>>>>>> http://www.itk.org/mailman/listinfo/insight-users
>
>
More information about the Insight-users
mailing list