[Dcmlib] Pixel Representation =1

[Jean-Pierre ROUX]

>Ok je comprends plus la question.
>
> $ vtkgdcmViewer caporg1.dcm
>...
>
>Range:-1500,1705
>
>
>ca m'a l'air correct non ?

Les valeurs sont entre -1500,1705 sur disque; elles sont entre 
-1500,1705 en mémoire, et VTK les affiche correctement (merci, 
Kitware)

>>>>
Le commentaire ci dessous
*          The responsability of checking this value is left to the caller
*          (NO transformation is performed on the pixels to make then >0)
est correct.

Ce que souhaitait Li Zhou, c'est que gdcm transforme pour lui des 
pixels signes (dont certains sont négatifs), en pixels non signés 
(tous positifs).
Et nous avions decidé, légitimement, de ne pas le faire (pa plus que 
VTK ne le fait)
La seule modif violente que nous faisons, c'est d'unifier MONOCHROME1 
et MONOCHROME2, afin que les valeurs 'hautes' correspondent a du 
'brillant' et les valeurs 'bases' a du 'sombre', dans tous les cas.

JP

JP

>
>-M
>
>Jean-Pierre Roux wrote:
>>Mathieu Malaterre wrote:
>>
>>>JP,
>>>
>>>   Do you want me to answer that ? Or are you preparing an answer ?
>>
>>
>>Mathieu.
>>I remember a discussion we had (with gdcm team), a long time ago.
>>I suggested to transform the Signed Pixels into Unsigned Pixels, 
>>but we decided it was up to the user to do that, after reading a 
>>post from David Clunie, about troubles with 'Pixel Padding value' 
>>nad Hounsfield density.
>>
>>Moreover, Nuclear medical images, or PET images are sometimes 
>>Signed, without any correlation with Hounsfield density.
>>We *cannot* know automatically what we (gdcm) have to do with Signed values.
>>Only aware user can know that.
>>
>>Any comment?
>>
>>Jean-Pierre Roux
>>gdcm team
>>
>>>
>>>-M
>>>
>>>zhou13 at netscape.net wrote:
>>>
>>>>Dear Jean:
>>>>
>>>>I find this in gdcmFile.cxx.
>>>>
>>>>/**
>>>>* \brief   Check whether the pixels are signed (1) or UNsigned (0) data.
>>>>* \warning The method defaults to false (UNsigned) when tag 0028|0103
>>>>*          is missing.
>>>>*          The responsability of checking this value is left to the caller
>>>>*          (NO transformation is performed on the pixels to make then >0)
>>>>* @return  True when signed, false when UNsigned
>>>>*/
>>>>bool File::IsSignedPixelData()
>>>>{
>>>>  std::string strSign = GetEntryValue( 0x0028, 0x0103 );
>>>>  if ( strSign == GDCM_UNFOUND )
>>>>  {
>>>>     gdcmWarningMacro( "Pixel Representation (0028,0103) supposed to be "
>>>>                     << "mandatory");
>>>>     return false;
>>>>  }
>>>>  int sign = atoi( strSign.c_str() );
>>>>  if ( sign == 0 )
>>>>  {
>>>>     return false;
>>>>  }
>>>>  return true;
>>>>}
>>>>So, using GDCM doesn't guarantee that the signess of pixel will 
>>>>be handled correctly.   People must actively  call this method 
>>>>and  custom  transform  the  value.    A better way would be 
>>>>hiding these details in side the reader and people would always 
>>>>get the correct value regardless of the Pixel Representation 
>>>>settings.
>>>>
>>>>Regards,
>>>>Li Zhou
>>>>
>>>>-----Original Message-----
>>>>From: jpr at creatis.insa-lyon.fr
>>>>To: zhou13 at netscape.net
>>>>Cc: dcmlib at creatis.insa-lyon.fr
>>>>Sent: Mon, 13 Nov 2006 9:21 PM
>>>>Subject: Re: [Dcmlib] Pixel Representation =1
>>>>
>>>>zhou13 at netscape.net <mailto:zhou13%40netscape.net> wrote:   > 
>>>>Hello list,  >  > Does GDCM correctly handle the Pixel 
>>>>Representation tag? When the > Pixel Representation value is 1, 
>>>>the stored value in DICOM is two's > complement ( 16 bit signed 
>>>>short ). I have been using VTK's DICOM > reader but it can't 
>>>>handle this situation.  I didn't know VTK's DICOM reader had this 
>>>>kind of trouble. GDCM deals correctly with pixel representation. 
>>>>GDCM comes with a vtkGdcmReader() , with the same API than vtk's 
>>>>DICOM Reader.   > So i am investigating ITK's DICOM reader which 
>>>>is based on GDCM. I > have some studies from a GE ProSpeed CT 
>>>>which actually set the Pixel > Representation tag to 1.  If you 
>>>>download gdcm, just use vtkgdcmViewer2 yourDicomFileName to be 
>>>>sure it works. You can have a look at the dicom header using : 
>>>>PrintFile filein=yourDicomFileName  HTH  Jean-Pierre Roux from 
>>>>gdcm team.   >  > Thanks.  > Li Zhou  >  >  > > 
>>>>---------------------------------------------------------------------- 
>>>>-- >
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>_______________________________________________
>>>>Dcmlib mailing list
>>>>Dcmlib at creatis.insa-lyon.fr
>>>>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib

  Jean-Pierre ROUX
  CREATIS - CNRS UMR 5515, INSERM U 630
  Laboratoire de Radiologie Experimentale
  Hopital Cardiologique
  28 Avenue du Doyen LEPINE
  B.P. Lyon-Montchat
  69394 Lyon Cedex 03

  Tel      : (+33) 04 72 35 74 12
  Fax      : (+33) 04 72 68 49 16
  URL      : http://www.creatis.univ-lyon1.fr
  e-mail   : jpr at creatis.univ-lyon1.fr