[Dcmlib] [ImageLoader vs WaveFormLoader]

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

> Benoit Regrain wrote:
>
>> La question est de savoir si c'est un type d'image différent à 
>> prendre en
>> compte au meme niveau que le jpeg2000, etc.
>> Ou si c'est un autre type de fichier, comme DicomDir ou 
>> StructureReport (SR)
>>
>> JPR, Mathieu, vous en pensez quoi ?
>> D'accord, cela contient une image (au final), mais d'après JPR, elle 
>> n'est pas
>> comme les autres images puisqu'il n'y a pas de pixelData comme les 
>> autres images
>> Dicom...
>
>
> Pour moi la nouvelle archi aurai un gdcm::ImageLoader, un 
> gdcm::IconLoader ... Donc tu construit une classe par 'grosse' entree 
> binaire que tu sais interpreter. Dans notre cas, cette waveform on 
> connais toutes les valeurs de l'entete mais on sais pas interpreter 
> les donnees binaires. D'ou la raison du traitement particulier dans un 
> gdcm::WaveformLoader ... 


C'est effectivement un autre type de fichier, comme DicomDir, ou 
StructureReport, ou SR Text Storage, ou  SR Audio Storage,  ou Cardiac 
Electrophysiology Waveform Storage (il y en a une cinquantaine comme ca)

D'accord pour un WaveformLoader, ou un StructureReportLoader, etc (qui 
sont *autre chose* que des images, et ne contiennent pas d'image.
Je suis bcp + reserve en ce qui concerne un 'IconLoader', qui n'est 
qu'une champ (SQ) particulier du type de fichier 'image'.

Le 'chargeur d'icone', si on en fait un, ne devrait pas etre au meme 
niveau que les autres (il serait appelé sur des fichiers images, ou des 
DICOMDIR *en plus* de leur traitement normal, pas *a la place*)

JPRx

>
> My 2 cents,
> Mathieu
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>