[Dcmlib] Removal of virtual DictEntries : not so straight
mathieu.malaterre at kitware.com
Wed Jul 13 16:41:00 CEST 2005
Jean-Pierre Roux wrote:
> 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.
More information about the Dcmlib