[Dcmlib] vtkGdcmReader

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

> Ca serait vraiment genial de pouvoir eviter de relire l'entete. Le 
> probleme c'est que ca n'a pas vraiment etre prevu. Je sais pas comment 
> tu va pouvoir controler gdcmDocument/gdcmSerieHelper/vtkGdcmReader 
> pour qu'il s'entendent sur cette notion.

==> A mon avis, le FileHelper peut travailler correctement que sur des 
'Series de bonne foi'
(ce qu'il fait dans son état actuel).
Si on lui passe n'importe quoi en entree (par exemple toutes les images 
de gdcmData), le fait qu'il prenne *une fois* des options 'curieuses' 
(par exemple ordonner sur le FileName des images rigoureusement 
identiques, *y compris la position* -comme les images du DatSet 
compression de David Clunie- n'est pas choquant, et n'est probablement 
pas 'reparable' (sur quoi les ordonerait-on ?)

==> Ce qu'on pourrait faire, a peu de frais, c'est, lors de la creation 
d'un DICOMDIR, permettre à l'utilisateur de demander d'ordonner les  
'DicomDirImages' à l'intérieur d'une DicomDirSerie, selon le meme 
critere que SerieHelper.
Lors d'un relecture ulterieure de *notre* DICOMDIR par *nos* logiciels, 
nous n'aurions plus a faire parser les entetes par SerieHelper (il a 
deja fait son boulot, une fois pour toutes.
Le fait de rajouter ce qui *nous* faut dans *notre* DICOMDIR n'est pas 
choquant : c'est ce que font les constructeurs lorsqu'ils gravent un 
CDROM, en incluant des info a l'attention de *leur* logiciel clinique 
(rien a redire si ca respecte la norme DICOM)

Et quand *notre* DICOMDIR n'est pas présent?
On fait comme avant  (pas le choix) !

==> la lecture d'une 'pile d'images' par vtkGdcmReader implique, dans sa 
version actuelle, un premier parsing pour s'assurer que les images sont 
'coherentes', et un deuxieme, pour lire les pixels.
Ce que je propose, c'est de permettre a l'utilisateur de dire qu'il 
'saute' la verification de la coherence, lorsqu'il *sait* que ses images 
sont cohérentes.
La programmation est immediate :
->une methode pour positionner un indicateur
-> appel d'une version 'light' de  CheckFileCoherence( ) -15 lignes, 
deja ecrites-, qui ne ferait que recuprer les info de la premiere image, 
et les conserverait pour les autres images de la pile.
Ca diminue a coup sur par 2 le temps de parsing ...

==> Autre chose (mais plus compliquée) serait d'exposer les mécanismes 
de Lecture/Decompression, pour permettre a un utilisateur qui aurait 
deja recupere les info (et mises dans un DICOMDIR ou dans une DataBase, 
da'cceder directement aux Pixels, sans aucun nouveau parsing.
C'est ce que Theralys avait envisage de faire, il y a 2 ans, puis laisse 
tomber, car, justement, les mecanismes de decompression n'etaient pas 
publics -sur des images nom comprimées, il suffisait de faire fseek() + 
fread()  + swapZone(); sur des images comprimées, c'etait sans espoir.

JPRx

>
> Enfin sinon je suis pour a 100%,
> Mathieu
>
>
> Jean-Pierre Roux wrote:
>
>>> CheckFileCoherence( ) ne fait pas que vérifier les fichiers entre 
>>> eux. Il
>>> récupère aussi la taille de l'image finale.
>>> Ce que tu demande est donc impossible.
>>> Benoit
>>
>>
>>
>> Il faudra pourtant trouver qq chose :
>>
>> Actuellement, nous avons des series de 2000 images.
>>
>> Les lire avec la version actuelle de vtkGdcmReader implique le 
>> parsing des
>> 2000 entetes, pour voir si, par hasard, le Scanner n'aurait pas genéré,
>> dans le tas, une image protegée en lecture(?), ou une image ne serait 
>> pas
>> codée sur 8 bits alors que *la premiere* etait codée sur 16, ou qu'une
>> image serait de taille en 65*64, alors que *la premiere* etait de taille
>> 512*512,  de prendre en compte le fait qu'une image pourrait etre
>> muliframe alors que *la premiere* etait single frame, etc.
>> Puis, on parse les 2000 entetes *une deuxieme fois* pour lire les 
>> pixels...
>>
>> L'operation a un interet certain lorsque l'utilisateur a rangé lui meme
>> dans un directory des images dont il n'est pas absolument sur.
>>
>> Dans le cas d'images dont l'utilisateur est sur, il *faudra* pouvoir lui
>> donner la *possibilité* d'eviter ce double parsing (sur *une image*, ca
>> n'a pas d'importance, sur *2000 images*, c'est dramatique !)
>>
>> Ce que je propose, apres lecture + detailée du code, c'est de donner la
>> possibilité a l'utilisateur (par positionnement d'un flag) de provoquer
>> l'execution d'un CheckFileCoherence() 'light', correspondant a la seule
>> partie 'else' du test
>>      if (FoundReferenceFile)
>> pour *la premiere image* seulement.
>>
>> C'est 15 lignes de code, qui positionnent les caracteristiques de 
>> l'image
>> (NY, NY, NZ, nb bits/pixel, signe O/N, etc).
>>
>> Et si l'une de ces images n'est pas bonne?
>> Il y aura de la merde a cet endroit, au lieu d'y avoir le plan noir qui
>> aurait ete insere par le 'full' CheckFileCoherence() , et 
>> l'utilisateur ne
>> pourra s'en prendre qu'a lui même.
>> (Pareil que s'il y a un plan noir, d'ailleurs)
>>
>> Any remark?
>>
>> JPRx
>>
>>
>>
>>
>>> ----- Original Message -----
>>> From: "Jean-Pierre Roux" <Jean-Pierre.Roux at creatis.insa-lyon.fr>
>>>
>>>> La methode vtkGdcmReader::CheckFileCoherence() verifie de maniere
>>>> exhaustive tout ce qui peut être verifié afin de s'assurer que
>>>> l'ensemble
>>>> des fichiers avec lesquels on se propose, par exemple, de faire un
>>>> volume,
>>>> sont coherents entre eux.
>>>>
>>>> Bonne idée, mais ca fait un parsing de l'entete Dicom en plus.
>>>>
>>>> - La plupart du temps, l'utilisateur a deja verifié ses données 
>>>> *avant*
>>>> (SerieHelper ou autre)
>>>> - Si l'utilisateur lisait des Raw Files, on serait obligé de lui faire
>>>> confiance
>>>> - On prend le premier fichier comme fichier de reference, alors qu'il
>>>> est
>>>> equi-probable que ce soit *lui* qui soit faux.
>>>>
>>>> Ne pourrait-on pas rajouter une methode SetNoCheck( ) ou autre qui
>>>> permettrait a l'utilisateur de dire qu'il est sur de ce qu'il 
>>>> fournit en
>>>> lecture et d'economiser ainsi un parsing de plus de toute la pile
>>>> d'images.
>>>>
>>>> Si l'utilisateur a vraiment passe n'importe quoi :
>>>> - sans CheckFileCoherence() ca petera, il n'aura qu'a s'en prendre 
>>>> a lui
>>>> meme.
>>>> - avec CheckFileCoherence( ), ca ne petera pas, mais il aura de bonnes
>>>> chances d'obtenir n'importe quoi ...
>>>
>>
>>
>> _______________________________________________
>> Dcmlib mailing list
>> Dcmlib at creatis.insa-lyon.fr
>> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>>
>