[Insight-developers] GDCM Data Dictionary

Thu Jan 6 10:05:01 EST 2005

Right now, I'm trying to pass the binary data through from the reader. I'm
base64 encoding the data and then decoding it. I am very close I think.

The reason I'm doing this is because the File Meta Information length is not
optional. Granted some readers don't use it, but, for example, I can't
create a dicom image with itk and read it into a commercial GE Advantage
Windows workstation.

The changes I'm making for the meta data handling are all in
itkGDCMImageIO.cxx.

Bill

-----Original Message-----
From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
Sent: Thursday, January 06, 2005 9:40 AM
To: Lorensen, William E (Research)
Cc: 'Luis Ibanez'; Insight Developers; dclunie at dclunie.com
Subject: Re: [Insight-developers] GDCM Data Dictionary

Bill,

	The name are not uniques:

6000 0051 US OLY Image Frame Origin
6002 0051 US OLY Image Frame Origin
6004 0051 US OLY Image Frame Origin

0020 0030 DS REL Image Position (RET)
2020 0010 US BIB Image Position
3002 0012 DS RT RT Image Position

0028 0010 US IMG Rows
6000 0010 US OLY Rows
6002 0010 US OLY Rows
6004 0010 US OLY Rows

	That's why I would prefer the tags too. I initially left the name as

keys because I thought that in real case applications we won't have 
duplicate name in the dicom header...

	From another point of view the DICOM writting has been a lot
improved 
in gdcm CVS. We can now write a DICOM from scratch (no need to read a 
DICOM in input). Therefore I would like to keep change in sync with gdcm.

	On the dictionary problem, the dictionary in GDCM is the 2003 one.
The 
2004 is in the CVS tree but is not taken into account. The format of 
this dictionary has changed the 2004 in gdcm now take into account the 
value multiplicity of a field and allow more robust checks. Since I 
didn't had time to integrate the new one we still keep the old one. On a 
side note some field names change over time:

"Patient Name" became "Patien's Name"

	BTW there are a lot of information drop from the dicom header since 
they refer to a private/shadow dictionary where we don't have access to 
the name.

my 2 cents,
Mathieu

Lorensen, William E (Research) wrote:
> I really don't like the tags as keys. I prefer the names, but I'm not sure
> how often they change. Should we change the gdcm dictionary to be
consistent
> with the DICOM standard? I'm willing to do it.
> 
> On a related note, do our itk changes to gdcm get rolled back into the
gdcm
> developers' tree.
> 
> Bill
> 
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
> Sent: Wednesday, January 05, 2005 3:49 PM
> To: Lorensen, William E (Research)
> Cc: Insight Developers; 'Mathieu Malaterre'
> Subject: Re: [Insight-developers] GDCM Data Dictionary
> 
> 
> 
> Good point...
> 
> In that perspective, it seems that using the DICOM tags
> as keys for the MetaDataDictionnay is a better choice.
> 
> Do you see any drawback on using the DICOM tags as keys ?
> 
> 
>     Luis
> 
> 
> 
> ----------------------------------------
> Lorensen, William E (Research) wrote:
> 
> 
>>But what if my application wants to change something in the
> 
> MetaDictionary?
> 
>>I don't want to have to change it with 2 calls. 
>>
>>-----Original Message-----
>>From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
>>Sent: Wednesday, January 05, 2005 2:54 PM
>>To: Lorensen, William E (Research)
>>Cc: 'Mathieu Malaterre'; Insight Developers
>>Subject: Re: [Insight-developers] GDCM Data Dictionary
>>
>>
>>
>>
>>Bill,
>>
>>
>>Two options come to mind:
>>
>>
>>
>>1) Using the numeric DICOM tags as the keys on
>>    the MetaImageDictionary.
>>
>>    - Advantage:  they are unique and standard
>>    - Disadvantage: users will have to know the
>>                    tags
>>
>>
>>2) Duplicating all the entries in the MetaDictionnary,
>>    so "Image Position" data is entered twice, the first
>>    time under a key "Image Position" and a second time
>>    under a key "0018 5100".
>>
>>    - Advantage: Users can look for both the textual
>>                 description or the formal tag
>>    - Disadvantage: the MetaData dictionnary will have
>>                 double the size.
>>
>>
>>
>>
>>    Luis
>>
>>
>>
>>
>>--------------------------------------
>>Lorensen, William E (Research) wrote:
>>
>>
>>
>>>Folks,
>>>
>>>As you can see, we are excited about having a robust dicom read/write
>>>capability in itk. And, GDCM is certainly the best way for us to reach
the
>>>goal.
>>>
>>>GDCMImageIO populates an itk MetaDataDictionary with most of the
>>
>>information
>>
>>
>>>in the DICOM header. The key for the dictionary values is a string that
is
>>>described in Insight/Utilities/gdcm/Dicts/dicomV3.dic.
>>>
>>>It looks as though this string is derived in some way from the DICOM
>>>Dictionary "Name". However, I looked at the DICOM standard and see that
>>
>>some
>>
>>
>>>Name's in dicomV3.dic do not match the names in the standard.
>>>
>>>For example,
>>>dicomV3.dic uses
>>>Image Position Patient
>>>bu the standard uses
>>>Image Position (Patient)
>>>
>>>Probably the names in the standard are not meant to be used at keys in a
>>>lookup, but it seems to me that it would be good to use the same names.
>>>
>>>Any thoughts on this?
>>>
>>>Bill
>>>_______________________________________________
>>>Insight-developers mailing list
>>>Insight-developers at itk.org
>>>http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>>
>>
>>
>>
>>
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers at itk.org
>>http://www.itk.org/mailman/listinfo/insight-developers
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
> 