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

[Jean-Pierre ROUX]

At 21:46 -0400 5/09/05, Mathieu Malaterre wrote:
>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).

Hi, Mathieu,
Do you mean some images are *not* 'gdcm readable' when their relevant 
Private Dicom Dictionary is not used? (in this case, it's a gdcm bug 
we (-I-) have to fix)
Or just that users want to get the value of some Dicom entries 
belonging to a Shadow (private) Group?
*With* or *without* the Private Dictionary, the value is available in memory.

If user knows, he wants to get the value of, say (0019,5100) element, 
he just writes :
gdcm::DocEntry *e = f->GetDocEntry(0x0019,0x5100);
and then :
   std::string value = f->GetDocEntryValue(e);
or
  uint8_t *value = f->GetDocEntryBinArea(e);

whether the value is 'std::string representable' or not
(user knows that)

The only differerence between using or not a Private Dict is when the 
Private element is 'Implicit VR' :
Without using a Private Dict, the value will always be considered as 
'non std::string representable', even if actualy it is (gdcm cannot 
guess) !

I can/shall add a 3 lines accessor to force the returned value to be 
a std::string
std::string value = f->GetDocEntryForcedStringValue(e);


Wouldn't it solve the problem ?

JP


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

The problem will to 'guess' which private Dict we has to use with a 
given image..


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

Nightmarish ...

>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.
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib

   Jean-Pierre ROUX
   CREATIS - CNRS UMR 5515, INSERM U 630
   Laboratoire de Radiologie Experimentale
   Hopital Cardiologique
   28 Avenue du Doyen LEPINE
   B.P. Lyon-Montchat
   69394 Lyon Cedex 03
 
   Tel      : (+33) 04 72 35 74 12
   Fax      : (+33) 04 72 68 49 16
   URL      : http://www.creatis.univ-lyon1.fr
   e-mail   : jpr at creatis.univ-lyon1.fr