[Dcmlib] Migration gdcm 0.6 -> 1.0 in ITK

[Mathieu Malaterre]

> On pourrait rajouter un . h avec des #define
> Ex :
> #define PatientName "0x0010,0x0010"
> ou
> #define PatientName "0010|00010"
> selon ce qui t'arrange.

Enfin je fais la difference entre un accesseur clairement indiquer genre
GetEntryByName qui incite le user a penser : bon ben je peux attaquer la 
base par le nom DICOM.

Et une methode:

static TagKey TranslateDicomNameIfPossibleToGeneraylizedKey(str::string)

(dont j'aurais avantageusement eu besoin... sigh).

La fonction en question peut etre super lente... (genre parcourir la 
hash et faire des comparaison de string...).

Enfin bon ca peut etre dangereux, c'est finalement pas plus mal que j'ai 
virer ca de ITK.

----------------------------------------------------------------

Toujours est-il que j'ai changer le comportement interne de ITK pour 
qu'il utilise une TagKey, mais ca ma fais raler sur le fais que je 
pouvais plus acceder a une entree maintenant que je manipule des TagKey.
Ca serait pas mal de faire le distingo entre le user et le dev:

Je concois que en interne gdcm utilise 2 unsigned short pour acceder a
l'element. (dans ce cas ces methodes devrait peut-etre etre protected)

Et ainsi dans l'API publique il n'y a plus qu'une seule methode d'acces
par TagKey (pour Get comme pour Remove).


La question a se poser. Est-ce qu'un utilisateur de gdcm a besoin
d'acceder une dictentry par son group,elem DICOM ?

Ou alors on est redondant, mais completement sur: Get / Remove ...

Mathieu
Ps: la solution redondance peut etre implementer efficacement car une 
methode peut etre 'inliner' (par rapport a l'autre)