[Dcmlib] Private Dictionaries in ITK-gdcm

Tue Sep 6 09:08:22 CEST 2005

At 5:54 +0200 6/09/05, Jean-Pierre ROUX wrote:
>At 21:46 -0400 5/09/05, Mathieu Malaterre wrote:

Mathieu,
Since I'm not a member of ITK ML, my post was rejected.
Could you forward it to the members (and ask them to send us images 
they cannot read when there is no Private Dict. -and the tag they 
need)
Thx
JP

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