[Dcmlib] Removal of virtual DictEntries : not so straight

Mathieu Malaterre mathieu.malaterre at kitware.com
Wed Jul 13 16:41:00 CEST 2005


Jean-Pierre Roux wrote:
> Hi.
> 
> It wont be so straight :
> 
> Virtual DictEntries were used in 2 cases :
> - When the 'explicit' VR found in the file is different than the one 
> found in dicomV3.dic
>   this can only appear for 'context dependant VR' (Pixel Data, Palette 
> Color, that can be OW or  OB, ou US, for instance)
>   this can be solved easyly by adding a char array 'Vr' to the 
> attributes of the DocEntry, instead of creating a virtual DictEntry.
>   When we process any DocEntry, we use all the attributes (Group, 
> Element VM, Name, but he VR),  of the standard DictEntry.


Make perfect sense. As well as we read group and element, if a file 
specify the VR *in the file* we should read it. The only problem I see 
is that in the case of Implicit VR, we will loose memory:

NumberOfDocEntry * sizeof(2 bytes)


Since we store the VR we can also now 'Validate' after reading the all 
VR actually matches the VR from the dictionary.

> -When we find a 'private element' (belonging to a Shadow group), or to a 
> Public Group, with a never defined before Element Number,
>  a Virtual DictEntriy was created. If we don't do, we have to store 
> Group, Element  as well,  inside the DocEntry (4 more bytes), and use them
>  when the pointer to the DictEntry is == 0.

Not sure I understand this one...

> Since VM and Name cannot be stored in the file, we don't have any 
> special trouble with them :
> either the DictEntry exists, and we use its VM and Name values
> or it dosn't, then it's GDCM_UNFOUND.
> 
> No objection ?

As long as all tests passes, I am fine with the changes.

Thanks
Mathieu



More information about the Dcmlib mailing list