[Dcmlib] not using double for high precision
mathieu.malaterre at kitware.com
Tue Mar 6 19:56:45 CET 2007
Jean-Pierre ROUX wrote:
> 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?)
I am pretty sure this is just because you cannot represent those values.
For instance start a python shell and type:
it should return
>> we should return from a function with the most appropriate c++ type:
>> 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.
Ok I'll have to think a little more about it.
Thanks for the comments,
More information about the Dcmlib