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

[Simon Warfield]

Mathieu,

  I have another DICOM issue I wonder if you know the answer.  I happen 
to have quite a lot of DICOM data that encodes a parameter called the 
b-value in tag 0043,1039 with a VR of IS.  Recent editions of the DICOM 
standard have made the tag 0018,9087 for storing this parameter, but our 
images don't use it.

    Can I modify the local DICOM data dictionary in some transparent way 
so that ITK will learn about this new tag  , or do I need to modify  
./Utilities/gdcm/src/gdcmDefaultDicts.cxx  and recompile the entire 
library ?

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



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