[Dcmlib] MONOCHROME1 vs MONOCHROME2

[Benoit Regrain]

Dans ce cas, il faut que l'utilisateur puisse définir son mode d'écriture.
Actuellement, toutes les images gray sont ecrite avec MONOCHROME2.
Donc si l'utilisateur lit une image avec efilm... il l'a voit d'une facon.
Puis y fait une modif et la fait reecrire par gdcm puis regarde cette 
nouvelle image avec efilm
il verra le negatif de l'image precedente... c'est un peu embetant tout 
ca...

Le problème est donc à réfléchir.
En ce qui concerne le développement de nouveaux éléments,
attend-t-on d'avoir la nouvelle structure pour les developper dedans ou pas 
?

Benoit


----- Original Message ----- 
From: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
To: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>
Cc: "Jean-Pierre Roux" <Jean-Pierre.Roux at creatis.insa-lyon.fr>; "Mailing 
list gdcm" <dcmlib at creatis.insa-lyon.fr>
Sent: Friday, April 29, 2005 3:30 PM
Subject: Re: [Dcmlib] MONOCHROME1 vs MONOCHROME2


> Benoit,
>
> Je pense que JP souleve une bonne question: si on ne gere pas le 
> rescale/reslope on ne devrait pas gerer le MONOCHROME non plus c'est un 
> comportement consistant non. Si la norme definit clairement que 
> MONOCHROME1 et MONOCHROME2 sont inverse et si les images sont valide par 
> rapport a la norme ben y'a pas grand chose a faire de notre cote.
>
> Si ca continue de poser probleme, il faudra revoir aussi gdcmPixelConvert 
> en:
>
>
>             PixelConvert
>          |                |
>   GrayScaleConvert    RGBConvert
>
> Ca laisse a l'utilisateur le choix entre l'acces pure au volume RAW
>  -> donc de faire un custom rescale/resclope (=ITK)
> ou bien
>  -> demander a PixelConvert de lui donner un volume pret a afficher
>
> Mathieu
>
>
> Benoit Regrain wrote:
>> ----- Original Message ----- From: "Jean-Pierre Roux" 
>> <Jean-Pierre.Roux at creatis.insa-lyon.fr>
>> Cc: "Mailing list gdcm" <dcmlib at creatis.insa-lyon.fr>
>> Sent: Friday, April 29, 2005 11:10 AM
>> Subject: Re: [Dcmlib] MONOCHROME1 vs MONOCHROME2
>>
>>
>>> *Normalement* MONOCHROME2, c'est le cas "normal" (low values =dark, 
>>> hight values =bright)
>>> MONOCHROME1, c'est le contraire (low values =bright,  hight values 
>>> =dark) ?!?
>>>
>>> Par 'normalement', il faut entendre 'd'apres la norme Dicom, dont tout 
>>> le monde se fiche ...'
>>> J'ai fait une modif, qu'il faudra probablement que je supprime, qui 
>>> prenait en compte le fait que c'est MONOCHROME1, inverse le codage, et 
>>> delivre une image 'normale' a l'utilisateur.
>>>
>>> --> Mauvaise idée, car on peut craindre que des logiciels prennent 
>>> *deja* en compte xette particularité, font leur propre transformation,
>>
>> Mais les logiciels qui s'appuyent sur gdcm prendront l'image correctement
>>
>>> --> Mauvaise idée, car des utilisateurs qui avaient l'habitude de 'voir' 
>>> leurs images avec une convention donnée (et dont ils n'avaient rien a 
>>> secouer), vont soudain la voir avec une convention inverse.
>>
>> On s'appuie sur la norme... gdcm evolue et prend mieux en compte la 
>> norme,
>> ce n'est pas un mal... bien au contraire
>>
>>> --> Mauvaise idée, car on peut raisonablement penser que ce champ n'est, 
>>> en general, pas rempli correctement, lorsqu'il vaut 'MONOCHROME1'
>>
>> Ben ca, c'est pas de notre faute
>>
>>>
>>> Bad shot...
>>> Je fais machine arriere
>>
>> NON, ca n'a aucune raison d'etre enlevé !
>>
>> Benoit
>> _______________________________________________
>> Dcmlib mailing list
>> Dcmlib at creatis.insa-lyon.fr
>> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>>