[Dcmlib] Classe PixelData

[Mathieu Malaterre]

Go for it !

Y'a un truc ou il faut que tu fasses attention, c'est si tu lis une 
image conpresser elle a une syntaxe d'image compresse'e.

AMHA, ca serait pas mal de garder l'image compresser (donc pas besoin de 
toucher a la syntaxe). Comme ca on peut lire une image dicom, 
l'anonymiser, la reecrire sur le disk sans overhead.

Et pour moi si l'utilisateur veut absolument RGB alors que l'image est 
grayscale... Il fait en deux etapes:

gdcmFile file
pixels = file.GetPixelStuff
void *rgb = pixels.ConvertTo( RGB )

et de la meme maniere :

gdcmFile file	//dicom jpeg
pixels = file.GetPixelStuff
void *uncomp = pixels.ConvertTo( UNCOMPRESSED )



gdcmFile file	//dicom avec YBR
pixels = file.GetPixelStuff
void *rgb = pixels.ConvertTo( RGB )

Donc la methode ConvertTo regarde le type interne d'image et converti en 
un autre type d'image. Dans l'avenir proche -pour pas compliquer la 
sauce- ConvertTo ne fais que des conversion de 'bon sens'. Si l'image 
est RGB, on peut pas demander YBR. Si l'image n'est pas compresser on 
peut pas demander compresser.
Mais dans l'avenir ca serait *vraiment* cool de lire un stack d'images 
DICOM non compresser et de les compresser en JPEG.

Mathieu


Jean-Pierre ROUX wrote:
> Bonjour.
> 
> L'option que j'avais prise pour lire les Pixels (economiser la place
> memoire, et, quand on le peut, le temps) etait, a l'usage, une mauvaise
> idee.
> On se retrouve avec des Pixels pouvant appartenir a deux gdcmFiles
> différents,  donc etre  pointes dans deux '7FE0,0010' differents, etc -pas
> pratique lorsqu'on desalloue !- ces PIxels etaient alloes soit dans la
> classe, soit, a l'exterieur, par l'utilsateur, etc
> 
> On (Eric, surtout, mais il avait raison) a decide de faire une classe pour
> les Pixels.
> Je l'ai nommee provisoirement gdcmPixelStuff, pour qu'il n'ya pas de
> confusion mentale avec les Pixels eux-memes.
> Ca va peter l'API, alors avant de commiter, et pour etre sur que ca
> conviendra a tt le monde (Mathieu et Manu, essentiellement, pour le
> moment), description du bouzin.
> 
> Le constructeur de gdcmFile ammene en memoire l'espace des pixels, tels
> qu'ils sont sur disque (l'image, ou la totalite de l'usine a gaz (table
> d'offet, table des fragments, fragments avec leurs delimiteurs, etc.
> Ce truc la est pointe par 7FE0,0010, ne bougera plus de la et sera detruit
> en meme temps que le gdcmFile.
> On dira en interne que
> gdcmFile HAS_A gdcmPixelStuff
> 
> 
> L'utilisateur (et c'est a lui seul de le faire), new son PixelStuff, choisi
> comment il veut ammener les pixels en moire (RAW ou RGB_IF_POSSIBLE)
> 
> gdcmFile* original = new gdcmFile( fileName );
> gdcmPixelStuff * pixSt = new gdcmPixelStuff( original);
> original->SetReadMode(GDCM_RAW);
> original->Read();
> uint8_t* pixels = original->GetImageData();
> uint8_t* lut = original->GetLUTRGBA(); // si lut == 0, c'etait du gris,
> sinon, gris+Palette
> 
> ou
> 
> original->SetReadMode(GDCM_RGB_IF_POSSIBLE);
> original->Read();
> unit8_t* pixels = GetImageData();
> 
> le 'don' des pixels d'un gdcmFile à l'autre (voir TestCopyDicom.cxx) se
> fera par :
> 
> gdcmFile* created = new gdcmFile( createdFileName );
> gdcmPixelStuff * createdPixSt = new gdcmPixelStuff(created);
> createdPixSt->SetImageData(pixels);  // deep copy
> 
> Remarque :
> 
> les methodes GetImageDataIntoVectorXXX  (qui permettaient à l'utilisateur
> de 'poser' les pixels lus en une position choisie par lui, d'un vecteur
> alloue par lui -pour, par exemple, creer a la volee un volume a partir
> d'une pile d'image sans avoir a recopier les pixels de l'image vers le
> volume(!)- n'ont plus lieu d'etre.
> 
> 
> Question :
> 'Fabriquer' des pixels RGB a partir des pixels GrayLevel et d'une LUT (
> methode GetReadImageData ) a-t-il encore lieu d'etre?  (c'etait un truc
> LibIDO oriented, inspire par le fait qu'on voulait a tout prix simplifer la
> vie a l'utilisateur)
> Je propose qu'on la supprime également.
> On sera debarrasse egalement de la methode SetReadMode(GDCM_RGB_IF_POSSIBLE);
> 
> Any comment?
> 
> BTW :
> pour les meme raisons, SetBinArea se fait par deep copy et non plus par
> passage de pointeur.
> 
> (c'est de nouveau TestCopyDicom qui a permis de mettre le bug en evidence.)
> 
> JPRx
> 
> 
> 
> 
> 
>  CREATIS UMR CNRS 5515 / INSERM 630
>  Laboratoire de Radiologie Experimentale
>  Hopital Cardiologique
>  28 Avenue du Doyen LEPINE
>  B.P. Lyon-Montchat
>  69394 Lyon Cedex 03
> 
>  Tel      : 04 72 35 74 12
>  Fax      : 04 72 68 48 16
>  URL      : http://www.creatis.insa-lyon.fr
>  e-mail   : jpr at creatis.univ-lyon1.fr
> 
> 
> 
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>