[Dcmlib] gdcm proposal (1) : ValEntry, BinEntry, SeqEntry
Jean-Pierre Roux
jpr at creatis.insa-lyon.fr
Fri Apr 29 17:39:50 CEST 2005
[...]
>>>
>>> Je crois qu'il faut commencer à donner des noms correct. Voici ce
>>> que je propose
>>> (je ne prefixe pas de gdcm pour ne pas alourdir les choses) :
>>> DocEntry : comme le DocEntry actuel (contient gr|elem + VR + value)
>>> dérivé en ValEntry, BinEntry, SeqEntry
>>
C'est bien mon avis!
La difference entre ValEntry, BinEntry, c'etait un truc artificiel du a
notre manque de talent pour faire qq chose d'intelligent, utilisable
directement en Python.
Sur disque, il n'y a QUE des BinEntry.
Le fait qu'on en transforme certaines en std::string, lors de la lecture
(pour les repasser en binaire lorsqu'on voudra s'en servir) n'est pas qq
chose a conserver!
(Si qq'un avait voulu traiter les vr =FD, en Python, c'est sur que les
FD seraient des ValEntries aujourd'hui.
Et puis, les LUT, selon qu'elles ont, sur disque une vr=OW ou US, elles
sont ou non des BinEntries, alors qu'il y a les memes valaeurs sur disque.)
Cette difference, c'est n'importe quoi !
La seule diiference, c'est entre les actuels 'ContentEntries' (elles
contiennent une valeur) et les SeqEntries ( elles contiennent un
ensemble des SQItems)
JPRx
More information about the Dcmlib
mailing list