[Dcmlib] Proposal: questions suite : Overlays

Mathieu Malaterre mathieu.malaterre at kitware.com
Tue May 17 16:40:31 CEST 2005


> ==> Vu que personne n'a JAMAIS vu une image avec des overlays, je sens 
> qu'on va en parler avec competence...

ok je cherchais a exprimer le besoin de lire 'avec retard' certain 
champs dont on a pas besoin si on se contente d'afficher l'image. Donc 
un meilleur exemple est: le gdcm.Writer. Lui a besoin de demander au 
Reader de charger a la volee tous les champs qui ont ete sauter. Il faut 
donc pouvoir exprimer de maniere simple dans gdcm.Writer:


void Write(ostream os, entry)
{
char buffer[4096];
if ( entry.WasSkipped )
   {
   entry.Load(buffer)
   os << buffer;
   }
else
   {
   os << entry.GetValue();
   }
}

Mis a part un champ texte avec l'annuaire telephonique je n'ai pas 
d'autre exemple de champ dont la taille serait > 4096.

>> ======================
>> Reader reader()
>> reader.SetFileName();
>> Document doc = reader.GetOutput()
>>
> ==> Ca, c'est l'ancien constructeur de gdcm::Document, n'est ce pas?

ooops je voulais faire un passage par reference...

> ==> Il y a aura la possibilite de dire, juste avant, si on veut ou non 
> charger les Shadow groups et les Sequences ?

bien sur ! C'est une feature killer qu'il faut garder.

> ==> Il faudrait egalement prevoir la lecture  :
> ==> 'frame by frame', en rendant la main a l'utilisateur apres chaque frame
> ==> 'from frame to frame' (on ne lit que les 'Frames Of Interest')
> ==> sinon, on ne s'en sortira pas plus que maintenant lorsqu'on aura a 
> faire a des images de 2000 frames, 1000x1000
> (elles existent deja)


Moi probleme c'est que je veux m'eloigner de cette approche et prefere 
plus objet, plus VTK, plus ce que tu veux:

gdcm.Reader
reader.SetFileName()

reader.ExecuteInformation(); //read num of frames

vol =  reader.GetVolume()

print "Here is the volume in the image", vol

# Let say vol = [512,512,10]

for in in range(0, vol[2])
   reader.SetVolume( vol[0], vol[1], i);
   reader.Update() # read a sub volume
   affiche( reader.GetOutput() )

Est-ce que le concept ExecuteInformation/ExecuteData est plus clair ?


> ==>On devra pouvoir dire si on charge les 'Palette Color' en 'niveau de 
> gris' + Palette, ou si on la tranforme directement en RGB?

C'est ce que j'essayais de dire avec les multiple loader. On devrait avoir:

gdcm.Reader reader
reader.SetFileName()

reader.ExecuteInformation()
r = reader.GetRepresentation()

if( r == GrayLevel )
   ImageGrayLoader loader;
else if( r == RGB )
   ImageRGBLoader loader
else if( r == RGBA )
   ImageRGBALoader loader
...more to come

loader.SetInput( reader.GetOutput())
loader.Update()


> ==> Ca  ramenera lequel d'overlay?

Meme principe que ImageLoader. Par defaut on prend le volume maximal. 
Sauf si l'utilisateur a preciser un sous volume. C'est pour ca que 
ImageLoader et OverLayLoader sont quasi identique: il ne faut pas 
dupliquer du code en interne !!

> ==>  peut y en avoir autant qu'on veut, sur une image :
> (ils sont decrits, soit dans les groupes 6000 et suivants, et la , par 
> nature, il ne peut y en avoir plus de 16, soit dans la Sequence, et la , 
> on en met autant qu'on veut)

Ok ca veut dire qu'il faut specifier:

OverLayloader ol;
ol.SetGroup( mygroup ) #user specified

print ol.GetOutput() #can be null

> ==> Un offset pour chacun des Overlays, oui.

ok

> ==> Pour lire un Overlay (ou une Curve), c'est fseek + fread.
> ==> Grace au diable, ils n'ont pas prévu de les compresser ....

Meme si les overlay ne sont pas compresser. On doit etre capable de lire 
l'image frame par frame meme si elle est en jpeg. Donc ou lieu d'un 
fseek, il faut faire:
1. fseek(jpeg_start_offset) puis
2. jpeg_fseek(i*num frame)

(en tres tres gros, mais je pense savoir le faire avec ijg).

> ==> c'est gdcm::Document moins les piteries qu'on fait avec les 'int' 
> pour les transformer en 'gdcm::string' ?

Alors dans ce cas comment on reutilise le code dans les sequences ? le 
parser 'pur' doit etre accessible au deux aussi facilement: sans 
dupliquer de code !

> ==> c'est une partie de gdcm::FileHelper, + integration de choses qui se 
> trouvent dans gdcm/Example ?

Je rajouterai
- une classe qui transforme un vecteur en chaine dicom separer par de \.
- une classe qui transforme une chaine (char */ std::string) en chaine 
DICOM propre
...

Merci pour tes commentaires,
Mathieu



More information about the Dcmlib mailing list