[Insight-users] GDCM orientation issue....

[Neil Weisenfeld]

Hi Mathieu,

Thanks for your offer of help.  I ran my code in a debugger so I could 
trace through what's happening and here's the problem:

One of our standard scan protocols is a dual-echo spin-echo sequence. 
This is delivered by the scanner typically as a DICOM dataset with every 
  odd slice being the early echo scan and every even slice being the 
late echo scan.  The current implementation of 
GDCMSeriesFileNames::GetInputFileNames does indeed attempt to sort based 
on ImagePositionPatient, but silently falls back to image number, as you 
  mentioned, if this fails.  In the case of our data, it fails because 
there are two slices at each position.

When assembling a volume from this data, it certainly makes sense to 
fail if multiple slices occupy the same position in space -- this 
violates the structural assumptions of the Image.  In my case, however, 
I was sending only every other filename to the ImageIO in a single call 
and generating two separate volumes -- completely valid given the data.

It would seem like it could be possible to still sort the file names 
based on IPP, even if there are multiple slices at each IPP.  The issue, 
of course, is how "ties" are decided in a reproducible manner.  I 
haven't looked at the code enough to see if it would be possible to 
break ties using one of the secondary methods, but it seems like that 
would be the desirable behavior in our case.

Furthermore, it would be nice if the sorting strategy were not 
transparent to the (interested) end user-developer, as it clearly 
impacts the structure of the data.  Maybe the chosen strategy could 
simply be saved and available for query.

I'd be happy to look into coding the desired changes if the strategy 
pans out as a sensible one.  Let me know what you think.


Regards,
Neil


p.s. -- I have this crazy dream that our data can finally come off of 
the scanner and be entered directly into an ITK registration+resampling 
algorithm without the need for hand tweaking of orientation issues. 
We're getting very close to that point thanks to everyone's efforts.


Mathieu Malaterre wrote:
> Neil,
> 
>     This is entirely possible.
>     Could you please run:
> 
> ./bin/DicomImageReadPrintTags filename | grep Position
> 
>     It should return like:
> 
> Image Position Patient = ...
> 
>     If not then you have either a broken DICOMv3 file or a good old 
> ACR/NEMA file. Anyway in both case gdcm fail back to the following 
> mechanism: When the ordering can not be done based on IPP, it then looks 
> for Image Number, and if Image Number cannot be found it fails back on a 
> simple filename ordering.
> 
> Mathieu
> Ps: Feel free to privately send me one of your DICOM file so that I can 
> examine it.
> 
> Neil Weisenfeld wrote:
> 
>> Ah, makes perfect sense. I need to dig a bit deeper to see what is 
>> going on.  It's possible that the ImagePositionPatient based sorting 
>> is failing and it silently falls back to filename ordering.
>>
>> Neil
>>
>>
>>
>> Simon Warfield wrote:
>>
>>> My understanding is DICOM guarantees the coordinate system is right 
>>> handed and that the 'unencoded' direction cosine is the cross-product 
>>> of the other two.
>>> This tells you about the axes of the coordinate system.
>>> ftp://medical.nema.org/medical/dicom/2004/printed/04_03pu3.pdf  page 
>>> 275 guarantees the coordinate system is right handed.
>>>
>>> See also the discussion on Patient Orientation here:
>>> http://www.faqs.org/faqs/medical-image-faq/part2/
>>>
>>>
>>> There is not an obvious way to determine what constitutes 
>>> 'consecutive' slices or the first and last slices other than from the 
>>> Image Position (Patient) tag. For example, I don't believe you can 
>>> infer 'consecutive' from the file name or part of the file name, or 
>>> from the 'instance number' (a tag with an undefined start value and 
>>> an undefined ordering but which identifies each image).    All I can 
>>> see you can do is to sort the slices based on the Image Position 
>>> (Patient) tag and this will run from the most negative position to 
>>> the most positive position along the Z axis defined by the direction 
>>> cosines.
>>>
>>>
>>>
>>>
>>>> I apologise if I'm adding unnecessarily to the pile.
>>>>
>>>>
>>>>
>>>> Neil
>>>>
>>>>
>>>> _______________________________________________
>>>> Insight-users mailing list
>>>> Insight-users at itk.org
>>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>