[Insight-users] Image Series Order - itk::ImageSeriesReader, SetReverseOrder

M. Wirtzfeld wirtzfeld at rogers.com
Wed Jul 9 21:52:49 EDT 2008



Good evening, Luis, Mathieu.  Thank you both for your responses.


To address your comments,


Luis - The source-code (compiled against version 3.4 of ITK) makes  
use of the itk::OrientedImage class.


Mathieu - The  itk::DICOMSeriesFileNames class is being used to  
generate the ordered filename sequence.  The current MR data-set is  
made up of two Series Unique IDentifiers (UIDs;  apparently a result  
of acquiring the images on three to four year old MR equipment - from  
what I have been told), while the current CT data-set is made up of a  
single UID.

Based on the ITK documentation (excerpts for both series filename  
classes noted are appended at the end of this e-mail), it appears the  
itk::DICOMSeriesFileNames class is better suited to handle multiple  
series identifier cases;  it is noted that the  
itk::GDCMSeriesFileNames class handles only one series identifier.



I should note that the itk::ImageSeriesReader uses the  
itk::GDCMImageIO class as the image-type by passing a pointer of this  
IO-type to the reader-object using the SetImage method.

Given the apparent need to use the itk::DICOMSeriesFileNames to  
handle the multiple series identifiers making up the volume, perhaps  
the itk::DicomImageIO class should be used in place of the  
itk::GDCMImageIO class?  I do not have knowledge and working  
experiences with DICOM images, so I would speculate the need for  
consistency - (DICOM series, DICOM reader) or (GDCM series, GDCM  
reader).  Or, in most cases, are these two image-IO types inter- 
changeable?


Thank you again,

Michael.


Michael Wirtzfeld
Robarts Imaging
London, Ontario - Canada


-----------------------------
  itk::GDCMSeriesFileNames

Generate a sequence of filenames from a
  series.

This class generate a sequence of files whose filenames points to a  
DICOM file. The ordering is based on the following strategy: Read all  
images in the directory (assuming there is only one study/serie)

1. Extract Image Orientation & Image Position from DICOM images, and  
then calculate the ordering based on the 3D coordinate of the slice  
2. If for some reason this information is not found or failed,  
another strategy is used: the ordering is based on 'Image Number' 3.  
If this strategy also failed, then the filenames are ordered by  
lexicographical order.


-----------------------------
itk::DICOMSeriesFileNames

Generate an ordered sequence of filenames.

This class generates an ordered sequence of filenames based on the  
DICOM tags in the files. Files can be sorted based on image number,  
slice location, or patient position. The files in the specified  
directory are grouped by SeriesUID. The list of SeriesUIDs can be  
queried and the filenames for a specific series extracted.


-----------------------------




On 8-Jul-08, at 3:23 PM, Luis Ibanez wrote:

>
> Hi Michael,
>
>
>                 Welcome to ITK !
>
>
> Thanks for the detailed description of your problem.
>
> With that, you are starting with a good precedent  :-)
>
>
> If you are finding necessary to play with the order of
> reading the DICOM slices in order to get the anatomical
> orientation of the images to match, then chances are that
> the image have been acquired with different orientations.
>
> The good news for you is that ITK provides classes for
> correctly taking image orientation into account.
>
>
> What you want to do first is to replace the use of
> "itk::Image" in your code, with "itk::OrientedImage".
>
>
> The OrientedImage will make sure that the image orientation
> that is encoded in the direction cosines stored in the
> DICOM header, is propagated and taking into consideration
> at every step of the image registration process.
>
>
> Once you introduce the itk::OrientedImage in replacement
> for the itk::Image, you shouldn't need to manipulate the
> slice order in the ImageSeriesReader class.
>
>
> Note that for this,
> You should use ITK 3.6 or a later CVS version.
>
>
> Please give it a try and let us know if you find any
> problems.
>
>
>
>    Thanks
>
>
>       Luis
>
>
>
> -------------------
> M. Wirtzfeld wrote:
>> Good afternoon,
>> We are currently writing registration code to handle mono-modality  
>> and multi-modality image registration using CT and MR data-sets.
>> At the present time, the code is able to perform registration  
>> using both of these data-sets.  The fixed-image is two-dimensional  
>> (treated as three-dimensional image-type by the code) and the  
>> moving-image is a volume created from a sequence of two- 
>> dimensional DICOM slices.
>> Using the itk::ImageSeriesReader class, mono-modality CT  
>> registration requires the SetReverseOrder method of this class to  
>> be called with a "true" boolean value and MR registration requires  
>> a "false" boolean value when the respective volumes are created.
>> I have ensured that the maximum-step used by the optimizer is  
>> properly set in both cases.
>> I believe the root of this requirement lies in the meta-data of  
>> the DICOM images that comprise the CT and MR data-sets, but I do  
>> not know why or what to look for in order to help find an answer.
>> I have not used ITK extensively and this is my first experience  
>> with image-processing.
>> Any help is greatly appreciated,
>> Michael.
>> Michael Wirtzfeld
>> Robarts Research
>> "Prefer the standard to the offbeat." - Strunk & White
>> --------------------------------------------------------------------- 
>> ---
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users

M. Wirtzfeld

"Prefer the standard to the offbeat." - Strunk & White




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20080709/6be432c2/attachment-0001.htm>


More information about the Insight-users mailing list