[Dcmlib] [Gdcm2] Re: Re: Question existentielle

[Mathieu Malaterre]

Comme je l'avais explique, effectivement j'ai essaye d'optimiser en gardant le cas de requete multiples. Ce que je fais c'est parcourir le fichier DICOM en ne lisant que les groupes length et construire une sorte d'index pour chaque groupe (file offset). Donc on peut effectivement acceder directement au groupe 7fe0 facilement.

Je suis en deplacement, sur mon portable Win32 je fais pas de gros progres en ce moment, mais la base est la.

Mathieu
Ps: bien sur dans le cas de DICOM sans group length l'optimization est moins visible, et meme chose dans le cas de groupe length tout pourri. Dans tous les cas on ne charge quasiment rien en memoire : nb groupe * sizeof(file offset)

> Emmanuel Olart wrote:
> 
> > Salut JP,
> >
> > Je suis dans une optique d'amélioration des performances de notre algo 
> > de lecture d'images basé sur GDCM  1.2.
> > Existe t-il un moyen de lire une image sans lire son en tete ?
> 
> Avec gdcm1.xxx, non
> :-(
> 
> > Je sais que certaines infos (type de codage, swapcode, endiannity, 
> > etc) sont vraiment necessaire a la lecture des images : si on imagine 
> > que je stocke les infos nécessaires à la lecture dans une base de 
> > donnée pour eviter de reparser les entetes, y aurait il un moyen que 
> > je repasse a GDCM ces infos afin qu'il ne lise *QUE* les datas ?
> 
> GDCM2 est capable de faire ca.
> (il y a un FileSeeker qui parcourt a toute vitesse sans rieen charger 
> -en reperant simplement l'offset de debut de chaque groupe)
> Tu peux ensuite demander d'ammener en mémoire les seuls champs qui 
> t'interessent -voir un exemple dans 
> /gdcm2/gdcm/Tests/Parser/TestAllLoadMinimumStuff.cxx-
> 
> > Cela te parait il possible ou bien est ce de la science fiction dans 
> > l'état actuel des choses ?
> >
> > D'autre part, en ce qui concerne GDCM 2.0 qui devrait régler une 
> > partie de mes problèmes de performance, as tu une idee du delai 
> > necessaire pour une premiere finalisation de cette version ?
> 
> J'attends que Mathieu nous donne le feu vert pour utiliser ses methodes 
> 'de bas niveau', et construire par dessus des methodes 'de haut niveau', 
> produisant le minimum possible de modif par rapport a l'API actuelle.
> JP
> 
> >
> > Manu
> >
> > -- 
> > Emmanuel OLART, IT Manager
> > *THERALYS*
> > Diagnostic & Therapeutic Image Analysis in Clinical Trials
> >
> > Address : Bioparc, 60 av. Rockefeller, 69008 Lyon, France
> > +33 (0)4 26 23 05 05 (Phone)
> > +33 (0)4 26 23 05 06 (Fax)
> > Email : eolart at theralys.com <mailto:eolart at theralys.com>
> > THERALYS <http://www.theralys.com/>
> 
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&opÌk
_______________________________________________
Gdcm-developers mailing list
Gdcm-developers at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdcm-developers