[Insight-developers] Re: [Insight-users] GDCM orientation issue....

[Simon Warfield]

Neil Weisenfeld wrote:

> 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.

It would be possible to order this type of data by first sorting on 
ImagePositionPatient, and then for slices that have the same position 
(which is perfectly legitimate) to sort based on EchoNumber (0018,0086).

Alternatively, perhaps the interface could allow the specification of a 
particular EchoNumber and only files with a matching EchoNumber would be 
read and sorted.

>
> 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
>>>
>>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers



-- 
Simon K. Warfield, Ph.D. warfield at bwh.harvard.edu Phone:617-732-7090
http://www.spl.harvard.edu/~warfield           FAX:  617-582-6033
Associate Professor of Radiology,          Harvard Medical School
Director, Computational Radiology Laboratory
Thorn 329, Dept Radiology,  Brigham and Women's Hospital 
75 Francis St, Boston, MA, 02115
MA 280, Dept Radiology, Children's Hospital Phone: 617-355-4566