[Dcmlib] Classe PixelData

[Jean-Pierre ROUX]

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