[Dcmlib] [DICOM] Ongoing effort for supporting Private Dictionaries in ITK-gdcm

Mathieu Malaterre mathieu.malaterre at kitware.com
Tue Sep 6 03:46:14 CEST 2005


Hello,

	There has been some recent discussion for improving support of private 
dictionary in ITK, namely it's dicom library: gdcm. For now gdcm has 
only very basic support of additional dictionaries. In fact the 
structure that hold the lookup from a DICOM tag to it's name, is a 
std::map. Therefore we can only lookup one and only one tag (since it's 
the key of the std::map). Unfortunately private dictionary can be shared 
across manufacturer (eg. philips/siemens/SPI). And often the 
manufacturer reuse old tags for there newer stations. Thus the current 
implementation of gdcm only allow loading one dictionary (or else we 
might have collisions). As a side note, so far only two or three tags 
from private dictionary have been reported as being needed to read the 
image (that's the reason why gdcm was initially designed without support 
for those).

	The other approach would be to have one std::map per dictionary (eg. 
the public one and then one private per station/manufacter). Therefore 
the problem of collisions will be avoided. Drawbacks: the time to lookup 
is no longer O(log(n)) but O(nb_dict*log(n)) for the worse case. This 
also means that we have to hold in memory much more dictionaries.

	Anyway the work can be done -I believe- without breaking gdcm API, only 
internal structures will be changed. But this would be a very long 
effort as there are multiple vendor, and multiple station(*). Everyone 
of which require generating a custom dictionary to describe it.

What is the current need of such feature in ITK community ?

Comments welcome,
Mathieu

Just for fun here are the station for GEMS:
Applicare/RadWorks/Version 5.0
Applicare/RadWorks/Version 6.0
Applicare/RadWorks/Version 6.0/Summary
DLX_ANNOT_01
DLX_EXAMS_01
DLX_LKUP_01
DLX_PATNT_01
DLX_SERIE_01
GEIIS
GEMS_3DSTATE_001
GEMS_ACQU_01
GEMS_ACRQA_1.0 BLOCK1
GEMS_ACRQA_1.0 BLOCK2
GEMS_ACRQA_1.0 BLOCK3
GEMS_ACRQA_2.0 BLOCK1
GEMS_ACRQA_2.0 BLOCK2
GEMS_ACRQA_2.0 BLOCK3
GEMS_ADWSoft_3D1
GEMS_ADWSoft_DPO
GEMS_AWSOFT_CD1
GEMS_AWSoft_SB1
GEMS_CTHD_01
GEMS_CT_CARDIAC_001
GEMS_CT_HINO_01
GEMS_CT_VES_01
GEMS_DRS_1
GEMS_GENIE_1
GEMS_GNHD_01
GEMS_HELIOS_01
GEMS_IDEN_01
GEMS_IMAG_01
GEMS_IMPS_01
GEMS_IQTB_IDEN_47
GEMS_PARM_01
GEMS_PATI_01
GEMS_PETD_01
GEMS_RELA_01
GEMS_SENO_02
GEMS_SERS_01
GEMS_STDY_01
GEMS_YMHD_01
GE_GENESIS_REV3.0
Mayo/IBM Archive Project


And some of the vendors(groups) are:
Camtron
GEMS
Picker
Siemens
Vli
Acuson
ISG
Papyrus
Toshiba
Agfa
Elscint
Philips
SPI

(*) Without mentioning that you have to parse a pdf file to generate a 
txt file, which usually contains typoes, and require manual 
investigation to fix the errors.



More information about the Dcmlib mailing list