[Dcmlib] not using double for high precision

[Jean-Pierre ROUX]

At 15:52 -0500 5/03/07, Mathieu Malaterre wrote:
>Dennis wrote:
> > Hi,
> >
> > In gdcm::File, float File::GetXOrigin() will lost some precision. I
> > think it should provide as: double File::GetXOrigin()...
> > for example, if -13.1 is converted to float in GetXOrigin(), actually
> > it will return as -13.1000000381470.
>
>No :)
>In the next generation of GDCM, it will be much more strongly typed. If
>the DICOM standard specify a Tag should be expressed as 16bits floating,

--> Mathieu : float are 32 bits longs ;-)

But the problem remains :
'Pixels Spacing' is expressed as 'decimal string' e.g. : "3.5\3.5"
So is 'Image Position (Patient)'.
If we loose information at conversion time because of the 
float/double (32bits/64bits) problems, we loose information.
(OK, it's only a 0.0000001 percent error, but the result looks 
strange, doesn't it?)

>
>we should return from a function with the most appropriate c++ type: float.
>So in conclusion, no you are not loosing precision, you are explicitly
>made aware by GDCM of the DICOM standard :)

This is true for the 'Float' Value Representation, not for the 
'Decimal String' VR.

Jean-Pierre Roux


>
>-M
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib

   Jean-Pierre ROUX
   CREATIS - CNRS UMR 5220, 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/~jpr