[Dcmlib] TestCopyDicom

[Jean-Pierre Roux]

>Mathieu Malaterre wrote:

> JP,
>
>     Est-ce que tu peux jeter un oeil sur TestCopyDicom ? ITK a une test
qui casse toute les nuits, et ca correspond grossomodo a
TestCopyDicom. En fait je suis juste interesse par
dicom-sc_cs-1.dcm, si les autres images ne passe pas ca fais rien.
Mais dans l'urgence j'ai vraiment besoin de celle la.


OK.
TestCopyDicom se merde également sur ce fichier.
Je vais regarder ca.

>
>     En fait j'ai besoin de savoir si oui ou non c'est possible de creer une
> image DICOM en copiant un par un les champ DICOM ou c'est pas prevu dans
> gdcm ? Dans les commentaires j'ai vu que j'avais commenter puis
> decomenter un accesseur. Tous ce qu'il me faut en fait c'est vraiment
> pouvoir iterer sur les champs un par un. Comme c'est une map derriere,
> qui peut etre assez importante, ca serait dommage de proposer comme seul
> interface une methode genre DumpTableAsVector. Donc les options que je
vois:


La solution qui est active actuellement, c'est la 2)
Ce n'est pas tres propre, c'est le moins qu'on puisse dire ...

Il faudra rajouter des methodes pour fournir un iterateur.

Le probleme (dans les deux cas) vient de ce que les' champs' Dicom  -qui
s'appellent maintenant gdcmDocEntry- de type SQ (sequence)
sont composes d'un ensemble de 'Sequence Item',
qui sont eux memes composes d'un ensemble de gdcmDocEntry, et ce, de
maniere recursive.
(tu peux faire PrintHeader sur, par exemple 
gdcmData/gdcm-MR-PHILIPS-16-Multi-Seq.dcm, pour visualiser l'ampleur du
desastre ;-)

Dans l'etat actuel, il faudrait gerer 'manuellement' cette recursivite
(c'est fait dans les methodes Print et Write), ce qui est un peu lourd...

Eric a une idee pour alleger le boulot de l'utilisateur final : etendre la
notion de 'clé', et dire que ce ne serait plus seulement
"numGroupe|numElement"
mais "numGroupe|numElement / numeroOrdreSequenceItem /
numGroupeDansLeSeqItem|numElementDansLeSeqItem ... etc"

Je suis plonge actuellement dans les chiures de mouches de GDCM_NOTLOADED,
de GetImageData et GetImageDataRaw
(on va surement rajouter une classe pour gerer proprement tout ca)

Dans l'immediat, tes soucis de TestCopyDicom *ne viennent pas* de ces pb
de recursivité
-J'ai un TestCopyDicom dans gdcm/Example qui pête egalement sur certaines
images-
(Tu peux decider de sauter les elements dont la VR est == "SQ", mais ca ne
changera rien)
Je vais essayer de tordre le cou a ca ce  W.E.

JPRx

>
> 1. Fournir un accesseur : un iterateur (typedef). Au besoin on rajoute
> un exemple comment l'utiliser. Donc il faut en gros deux methodes: begin
> et end, facile vu que map supporte begin et end.
>
> 2. Renvoyer directement la map, et l'utilisateur devra lire la doc stl
> pour savoir comment manipuler le bidule.
>
> 3. Sinon c'est la solution lourdingue, on dump toute la table des clefs
> dans un vector de string. Comme ca on peut iterer sur les clefs, et
> utiliser les clefs dans les methods deja existantes.
>
> Merci,
> Mathieu
>
> Ps: en fait TestCopyDicom dans ITK test:
> dicom-sc_cs-1.dcm
> 012345.002.050.dcm
> et les trois images de:
> http://www.itk.org/cgi-bin/viewcvs.cgi/Testing/Data/Input/DicomSeries/?root=Insight
> (elles ne sont pas dans la baseline, je crois)
>
>
Je vais les recuprer