[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