[Dcmlib] DICOM dict suite

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

>> J'avais, il y a longtemps, rajouté *une* ligne au dictionnaire, pour 
>> que l'on puisse, sans rien faire d'autre, parser les images Papyrus 
>> (l'utilisateur se debrouille alors pour en faire ce qu'il veut, ce 
>> n'est plus notre problème).
>> Tu l'avais supprimé pour des raisons idéologiques, ca ne marchait 
>> plus, je l'ai rajoutée, ca marche de nouveau.
>
>
> ok, on peut rajouter un test pour papyrus, pour que je me rende compte 
> qd je casse un truc.

Ca ne segfault pas, ca passe tout droit sans trouver les images...
Si tu mets en place ce que tu proposais (au niveau de Cmake, merger le 
'vrai' dicomV3.dic + le dico Papyrus+ les 4 lignes 'NIH made', ca 
marchera dans tous les cas.

>
>> Laisse tomber le dictionnaire Papyrus, on n'en a pas besoin pour lire 
>> les images Papyrus ... Notre dictionaire dicom va tres bien, 
>> moyennant l'ajout d'*une* ligne.
>
>
>
> Alors la je comprends plus, dans ton mail precedent tu expliquait 
> pourquoi il fallait a tout pris remettre des champs inexistants (*). 
> Mais maintenant tu change d'avis et ce n'est pas important de rajouter 
> les autres champs Papyrus, accessoirement il y a 4 type de champs SQ, 
> et d'apres -IMHO- mes souvenirs il est tres important de savoir quels 
> sont les champs SQ des autres, voila le dict actuel:
>

Oops !
J'achete.
Je n'avais pas vu qu'il y avait d'autres 'SQ' que le 0041 1050 SQ 1 
Image Sequence.
Dans le cas de Papyrus, ca marchait tout de meme, car les SQ ont leur 
'vraie' longueur, et non pas 0xffffffff.
les SQ autres que 0041 1050 SQ 1 Image Sequence sont simplement lues 
comme des BinEntries (inutilisables, donc, mais rien ne casse)
La 0041 1050 contient la description et les pixels de chaque image de la 
serie. Si le tag est absent, l'image n'est pas identifiée comme du 
Papyrus, et l'utilisateur ne peut rien en faire.

> 0041 0000 UL 1 Group Length
> 0041 0010 LO 1 Owner ID (PAPYRUS 3.0)
> 0041 1000 LT 1 Comments
> 0041 1010 SQ 1 Pointer Sequence
> 0041 1011 UL 1 Image Pointer
> 0041 1012 UL 1 Pixel Offset
> 0041 1013 SQ 1 Image Identifier Sequence
> 0041 1014 SQ 1 External PAPYRUS-File Reference Sequence
> 0041 1015 US 1 Number of images
> 0041 1021 UI 1 Referenced SOP Class UID
> 0041 1022 UI 1 Referenced SOP Instance UID
> 0041 1031 LO 1 Referenced File Name
> 0041 1032 LO 1-n Referenced File Path
> 0041 1041 UI 1 Referenced Image SOP Class UID
> 0041 1042 UI 1 Referenced Image SOP Instance UID
> 0041 1050 SQ 1 Image Sequence
>
>> Si tu tiens a avoir 3 fichiers différents, et de faire le merge *hors 
>> gdcm*, je n'ai rien contre.
>> Ton 'gdcm.dic' remplacera, lors de l'exec, l'ancien dicomV3.dic et ca 
>> sera tres bien.
>> Ce que je ne veut pas, c'est que l'on oblige l'utilisateur, avant de 
>> commencer a programmer, a savoir quel type d'images son appli doit 
>> pouvoir traiter (son programme segfault sur les images 'non prévues')
>
>
> Donc encore une fois qu'est-ce qui fais seg faulter ? Trop 
> d'information, pas assez d'information ?

Ce qui provoque un seg fault, c'est lorsqu'une SQ  n'est pas identifiée 
comme telle, et que sa longueur est 0xffffffff.
(ce n'est jamais le cas pour les images Papyrus)

JPRx

>
> (*)
> ---- david clunie sur comp.dicom -----
>
> >   0040 0552 SQ 1 Specimen Description Sequence
> No such attribute
> >   0040 0553 ST 1 Specimen Description
> No such attribute
> >   0040 09f8 SQ 1 Vital Stain Code Sequence
> No such attribute
> >   0040 a16a ST 1 Bibliographics Citation
> No such attribute
> >   0040 a992 ST 1 Uniform Resource Locator
>
> No such attribute
>
> I suspect these were taken for the draft for trial implementation
> of Sup 23 SR, which was problematic in many ways, not the least
> of which was that some of its attributes with the same number
> were re-used with different purpose and VR, etc.
>