In the C3D file format, 3D point data was originally intended to store marker position data within a calibrated volume.  Hence, the data would be homogeneous in the sense that units and relative scales of each point data item would be the same.  When stored in integer form, the stored 16-bit signed integer value must be multiplied by the POINT:SCALE floating-point scaling factor (header words 7-8) to yield a real world value – generally where all the data points are measured in millimeters.

The signed integer variable type represents an integer value from -32768 to +32767.  The scaling factor is dependent upon the calibration volume and is calculated when the data is stored such that the greatest precision is allowed over the entire volume of interest.

For example, if the largest dimension of the calibration is 4 meters then, assuming the calibrated volume begins at the global (0,0,0) reference location and contains only positive X-direction points with the largest dimension being X=4 meters, the scaling factor for length units expressed in mm would be

Scaling Factor = 4000 mm/32767step = 0.122 mm/step

                              0 . . . . . . . . . . . . .  4000 mm

+-------------------------+------------------------+

-32768                    0                    +32767 steps

Thus the resolution of the spatial locations is:

Resolution = 1 step * 0.122 mm/step = 0.122 mm

Clearly, problems can occur when the scale of the stored data reaches that of the scaling factor or resolution.  However, as can be seen from the example above, the resolution of integer data within a C3D file in this example is well within even the theoretical limits of most current 3D motion measurement systems.

Problems do arise however when software applications change the interpretation of the 3D data point.  For example, software applications have used the 3D point data type to store the results of internal calculations of non-3D information such as accelerations and moments derived from calculations in clinical software applications.  Depending on the scaling of these calculations, this can produce numbers that can not be accurately represented with the same POINT:SCALE factor required by the 3D point data.

Under these circumstances, moments in a system with dimensional units of mm and force units of N are commonly computed in units of Nmm.  This can lead to problems for users who manipulate the 3D point data within the application and then store the results in an integer format C3D file.  For instance, users may wish to scale the above mentioned Nmm values by dividing by 1000 to obtain the more commonly used units of Nm and then further dividing by the subjects body weight for normalization to obtain units of Nm/kg.  Such a conversion from Nmm to either Nm or Nm/kg can easily result in values on the order of 1 or even 0.1 which are significant in the context of their biomechanical importance.

When storing these values within integer 3D data variables only 8 numbers (steps) would be available to store values between 0 and 1 and all values between 0 and 0.1 would be treated as 0.0 (using the example above).

0                          1.0 mm                      0                           0.1 mm

+--------------------------                                +---------------------------

0                           8 steps                     0                            1 step

The loss of resolution during the conversion of the floating-point values to signed  integer values limited by the POINT:SCALE factor results in loss of data resolution when the results approach the POINT:SCALE value.

Since this truncation of the data occurs when the floating-point values are saved to a C3D file using the integer formats, the loss of resolution will not be apparent until the C3D file is later reloaded.  It is also worth noting that floating point data that has been filtered will become “noisy” if it is converted to signed integer values.  This is due to the loss of precision during the floating point to signed integer conversion process.  This is a particular problem at very low signal levels.

There are several ways to avoid this scaling problem.  Perhaps the most obvious is to be aware of the units and the ranges of interest as well as the resolution of the system and to scale appropriately within any application that may need to generate integer formatted C3D files.

A better solution would be to store the results of these calculations in a separate data section elsewhere in the C3D file where each stored variable could be assigned its own scaling factor.  However, until the C3D standard includes a common format specification for this type of storage, any data saved in this way would not be universally accessible.

In general, the safest solution, if data must be written to a C3D file in this manner, is to always specify the use of a floating-point format for C3D files and never convert floating-point formatted files into integer format.  However, since many older C3D applications cannot read floating-point formatted files this is not always an option.