[Dcmlib] vtkGdcmReader

Benoit Regrain benoit.regrain at creatis.insa-lyon.fr
Fri Apr 22 15:19:02 CEST 2005


Le plus propre (mais pas vtk-complient) serait de tout faire soit
dans le ExecuteInformation, soit dans le ExecuteData... a voir lequel
serait le mieux. J'essayerai de me trouver un peu de temps pour voir
ca la semaine prochaine (sans garantie).

En attendant, on peut déjà ouvrir les fichiers avec l'amélioration qu'a fait
JPR sur le chargement light d'une image... et je crois pas que ca ait été
déjà mis dans VTK cela...

Benoit


----- Original Message ----- 
From: "Jean-Pierre Roux" <Jean-Pierre.Roux at creatis.insa-lyon.fr>
To: <dcmlib at creatis.insa-lyon.fr>
Sent: Friday, April 22, 2005 2:37 PM
Subject: Re: [Dcmlib] vtkGdcmReader


>
>>
>> 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 




More information about the Dcmlib mailing list