[Dcmlib] GDCM et JPEG suite

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

> Salut,
>
>     Bon mon patch pour BigEndian et JPEG n'est pas a l'epreuve des 
> balles. qd le flux decompresse est YBR tout casse...
>
>     J'aimerais donc faire des modifs assez grosses dans la 
> decompression jpeg. Au lieu d'une methode static, gdcm_read devrait 
> etre membre d'une classe pour avoir access a l'information si l'image 
> est YBR ou pas. Car tout l'interet est qu'ici ijg gere la 
> decompression de jpeg ybr *directement*. Je suppose que ca serait plus 
> rapide de faire ca que ce qu'on fais en deux passes en ce moment.


-->On en est arrives a un stade ou il faut se poser la question de place 
memoire, et de la vitesse d'execution.

-->On a toujours presents a l'esprit les examens medicaux tels qu'ils 
etaient il y a 5 ans ...
Typiquement : 200 images 256x256.
Aujourdh'ui, il faut plutot tabler sur 2000 images 1024x1024 (exam du 
Scanner 'Cardio')
Il y a dans gdcm une 'belle' image multiframe de 30 frames, qui fait 65 
MegaOctets ...
Lorsqu'on aura a faire a des images de 300 frames, ca va commencer a 
craindre, en mémoire !
600 Mega  (si elle est RGB, multiplier par 3, et si elle est YBR ...) si 
on bosse avec vtk, rajouter cette même taille pour le vtkImageData.
Autant eviter d'encombrer la mémoire avec des données de travail dont on 
n'a clairement pas besoin (par exemple, garder les pixels avant 
decompression, ou les pixels 'passes en BigEndian' -ou en little- et qui 
seraint la juste pour nous simplifier la vie lors de l'ecriture.

--> a propos du 'hack sauvage' de Mathieu.
ca va effectivement etre l'epouvante si on raffraichit l'image affichée 
pendant qu'on l'ecrit sur disque en changeant l'endianess.
La solution simple, mais dramatqie en termes de place, c'est , le 
PixelWrite convertor, d'allouer une image -encore une !- temporraire, de 
swapper les pixels dans cette image, et de la supprimer ensuite.
L'idee de Jean-Michel Rouet, qui me plaisait, bien d'allouer un buffer 
de taille raisonable (8 ou 16 k), et de faire un boucle de 
move-swap-write jusqu'a  avoir parcouru toute l'image n'est pas 
applicable dans l'etat actuel des chose :
 Lorsqu'on lance l'ecriture, tous les DocEntry sont ecrits, tels qu'ils 
sont en mémore.

Il faudrait, pour pouvoir faire la manip suggeree par Jean-Michel (et 
c'est sur qu'il faudra proceder par des move-swap-write ), creer une 
classe derivee de BinEntry (qui serait, par exemple PixelEntry), qui 
prendrait en compte, dans sa methode Write, l'endianess.
Pour le moment seul 7FE0,0010 serait dans ce cas.
A terme, les icones, overlays -qu'on s'est promis de traiter, un jour- l 
e seront egalement.

JPRx




>
>     Qu'est-ce que vous en pensez ?
>
> Mathieu
>
>
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>