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

[Mathieu Malaterre]

Neil,

	This was discussed at some point during a ITK meeting, but was never 
integrated into ITK/gdcm. If you want to have a look at what is 
currently done in gdcm CVS, please go to:

http://cvs.creatis.insa-lyon.fr/viewcvs/viewcvs.cgi/gdcm/src/gdcmSerieHelper.cxx?rev=1.18&view=markup

You'll see gdcm::SerieHelper offer an API to add rule to discard 
particular image (SerieHelper::AddRestriction). In your case I believe 
you have to different EchoTime value. So what you would do is set 
SerieHelper to discard the first EchoTime, then point it to the 
directory, it should then read the proper volume discarding the other 
EchoTime value.

	If this indeed solve your issue, open a bug in the itk bug tracker and 
assign it to me. I'll see wether I can update gdcm to gdcm CVS, or 
simply just apply the necessary patch.

Regards,
Mathieu

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