WORD
Typical Value
Description
0
0x5000 | 2
Key (5000 hex) ORed with record number of parameter section (2).
1
-
Number of 3D points per field (i.e. the number of stored trajectories).
2
-
Number of analogue channels per field. One data WORD per channel is
stored.
3
-
Field number of first field of video data corresponding to 3d points
(1 based).
4
-
Field number of last field.
5
0 or 10
Maximum interpolation gap in fields.
6 -7
-
Scaling factor (float
< 0 pre-scaled; 3D data in REAL*4
>= 0 scale; 3D data in INTEGER*2
8
10
Record number where 3D data starts.
9
-
Number of analogue frames per video field.
10 - 11
50, 60, etc.
Video rate in Hz (float1).
12 - 148
-
(Undefined).
149
octal 12345
Key.
150
0
Number of defined time events.
151
-
Not used.
152 - 187
-
Event times (float1). Maximum 18 entries.
188 - 197
-
Byte format event switches:
0 = ON
1 = OFF (yes really!)
198 - 233
-
4 character event labels.
234 - 255
-
(Undefined).
BYTE
Typical Value
Description
1
1
Part of identification key.
2
80
Part of identification key (=50 hex).
3
1
Number of parameter records to follow (see below).
4
85
83 decimal + processor type (see below).
The processor type may have values as follows:
1 = PC-DOS
2 = DEC (VAX, PDP-11)
3 = MIPS processor (SGI, SUN)
Directly following this header, the parameter data is stored contigiously and may overlap record boundaries. The parameters themselves are organised into groups. Each parameter and group identifier starts with a header, the format of which is common between the two. Group identifiers are assigned a negative group number in the header and parameters belonging to the group are assigned the positive of that number. Group identifiers and parameters may appear in any order in the file.
The record count in byte 3 corresponds to the number of fixed length 512 byte records that constitute the parameters section. It should be noted that Vicon 370 currently always stores a value of 1 in the byte 3 parameter record count. It is recognised that this may often be incorrect. The 370 software does not make use of this value and instead scans the parameter section looking for specific parameters and stops when it finds a zero (length) value as the first byte of a parameter or group. This is necessary because although the number of parameter blocks are known, the extent to which the last block is used is not known. It is recommended that any software written to read C3D files generated by 370 should use the same algorithm for detecting the end of the parameters section.
e.g. Group "POINT" arbitrarily assigned the number -1 and with no description would be stored in 10 bytes as follows:
Parameter Format:
where: 'T' is the parameter type:
'dlen' is the length of the data and is determined by:
t = |T| i.e. the magnitude of the type
if (d == 0)
dlen = t
dlen = t * D1 * D2 * ... * Dd
If 'n' is negative, the group has been marked as locked and should
not be edited.
Note that for non-array parameters, the usual method of having 'd = 0' is directly equivalent to having 'd = 1' and 'D1 = 1', the only difference is that the second approach requires one extra byte of storage.
Also note that the storage order of multi-dimensioned array parameters follows the FORTRAN convention (for historical reasons). In this format, the dimension that changes more rapidly appears first. For example, the reconstruction volume (parameter "DATA_LIMITS" in group "SEG") is made up from two 3D vectors stored in the order:
MinX, MinY, MinZ, MaxX, MaxY, MaxZ
Using the convention, this is defined as a 3 by 2 array (rather than 2 by 3).Therefore, the correct definition for the parameter is:
d = 2
D1 = 3 (not 2)
D2 = 2 (not 3)
3D data for field 1
Analogue data for field 1
3D data for field 2
Analogue data for field 2
:
:
3D data for field Înâ
where Înâ is the number of fields stored:
Analogue data for field Înâ
(WORD 4 - WORD 3 + 1)
3D Data:
If the scaling factor ("SCALE" parameter from group "POINT", also stored
in WORDS 6 and 7 in the header record) is positive then each 3D data block
will contain the following format data for each stored trajectory (the
number of which is given by WORD 1 in the header record):
R = Residual, C = Camera Mask
Word 0 = X coordinate in reference coordinate system to be multiplied
by the scaling factor.
Word 1 = Y coordinate in reference coordinate system to be multiplied by the scaling factor.
Word 2 = Z coordinate in reference coordinate system to be multiplied by the scaling factor.
Word 3 : This word should be interpreted as follows:
If the word is -ve (i.e. bit 15 set) then the point is invalid (not observed by at least 2 cameras). X, Y and Z should be ignored but should all be zero.
Otherwise, the low byte represents the average of the residuals for
the measurement on the point and must be multiplied by the scaling factor.
If this is zero then the point is interpolated or otherwise generated.
The high byte has bits set corresponding to which cameras contributed to
the measurement of the point. Bit 8 of the word (bit 0 of the byte) represents
the first camera, bit 9 the second, etc. Again, all camera bits will be
clear for interpolated or otherwise generated data points.
If the scale factor is negative then the coordinates are already scaled and stored in float (REAL*4) format as follows:
Float 0 = Scaled X coordinate in reference coordinate system.
Float 1 = Scaled Y coordinate in reference coordinate system.
Float 2 = Scaled Z coordinate in reference coordinate system.
Float 3 = Residual and camera mask. This float should be converted to an integer and treated exactly as for Word 3 in the integer format described above, except that the scaling factor should first be negated to make it positive. In other words, if the integer is negative, the point is invalid. Otherwise, the lower 8 bits of the integer, when multiplied by the absolute value of the scaling factor, yields the residual and the remaining bits represent camera masks.
To convert the data into real world units:
real world value = (data value - zero offset) * channel scale * general scale
where: Îzero offsetâ is in the ãANALOG:OFFSETä
parameters
Îchannel scaleâ is in the ãANALOG:SCALEä
parameters
Îgeneral scaleâ is the ãANALOG:GEN_SCALEä
parameter
ANALOG: Group
Name
Type
Dimension
Usage
LABELS
ASCII
(L,N)
N labels of length L associated, by order, with analog channels in
data section. Note that there may be more than N channels, in which case
additional channels may be referenced by number in some applications. L
is typically 4 characters.
DESCRIPTIONS
ASCII
(L,N)
N descriptions of length L associated with corresponding analog channel
labels. L is typically 32 characters.
GEN_SCALE
real
scalar
General scaling factor applied to all analog channels. Often
set to 0.0024414 (10/4096) to derive voltage input from 10V 12-bit ADC.
Since different channels may be captured with different input ranges and
not all signals are required in volts, it is recommended that this value
be set to 1.0 with individual scaling applied to each channel (see SCALE
parameter).
SCALE
real
(N)
Scaling factor applied, with GEN_SCALE, to each analog channel to convert
raw a.d.c. data to physical variable UNITS.
OFFSET
integer
(N)
Offset to be subtracted from raw a.d.c. values before scaling.
UNITS
ASCII
(L,N)
N strings of length L indicating the analog measurement units for each
channel, e.g. V, N, Nm, etc. L is typically 4 characters.
USED
integer
scalar
Number of analog channels used. Total number of ADC samples stored
per video field must be an integer multiple of USED.
RATE
real
scalar
Analog sample rate in Hz
POINT: Group
Name
Type
Dimension
Usage
LABELS
ASCII (typically upper-case)
(L,N)
N marker labels of length L associated, by order, with trajectories
in data section. L is typically 4-30 chars. N is 1-255.
Note: There may be more or less than N trajectories; some applications
allow additional trajectories to be referenced by number.
LABELS2
ASCII
(L,N)
Additional labels beyond the 255 limit in LABELS. Note that LABELS3,
LABELS4, etc. parameters may also be present as necessary. In all cases,
N is 1-255 representing 256-510, 511-765, etc.
(Introduced in 370 version 2.5)
DESCRIPTIONS
ASCII
(L,N)
N descriptions of length L associated with corresponding labels. L
is typically 32 characters.
DESCRIPTIONS2
ASCII
(L,N)
Additional descriptions beyond the 255 limit in DESCRIPTIONS. Note
that DESCRIPTIONS3, DESCRIPTIONS4, etc. parameters may also be present
as necessary. In all cases, N is 1-255 representing 256-510, 511-765, etc.
(Introduced in 370 version 2.5)
USED
integer
locked
scalar
The number of trajectories stored in the data section. Note that USED
is set to the number of the highest applied trajectory label, whether from
LABELS list, or by default label numbering; #n. All trajectories
up to and including USED are stored, with "invalid" coordinates if no trajectory
has been assigned to the label.
UNITS
ASCII
(L)
String to indicate measurement units, e.g. mm, cm, m. Note that
this string should be defined when the calibration reference points are
entered (CRO file). L is typically 4 characters.
SCALE
real
locked
scalar
Scaling factor which converts integer C3D trajectory records into coordinates
in UNITS
RATE
real
locked
scalar
Video data field capture rate in Hz
DATA_START
integer
locked
scalar
Record (512 bytes) number of the start of data section
FRAMES
integer
locked
scalar
Total number of fields of video data stored in the data section.
NB This misuse of the word "frame" is common among VICON users.
INITIAL_COMMAND
ASCII
(78)
Command string interpreted by SID program.
X_SCREEN
ASCII
scalar
{X,Y,Z,-X,-Y,-Z} indicates which axis of reference coordinate system
should be displayed left-to-right across the screen.
Y_SCREEN
ASCII
scalar
{X,Y,Z,-X,-Y,-Z} indicates which axis of reference coordinate system
should be displayed bottom-to-top up the screen.
ANGLES
ASCII
(L,N)
N labels of length L. Trajectories with labels matching those
in this list are to be treated as angles rather than translations. The
units are always degrees.
(Introduced in BodyBuilder version 2.5)
SCALARS
ASCII
(L,N)
N labels of length L. Trajectories with labels matching those
in this list are to be treated as scalars rather than translations. The
value is held in the Z component with X and Y both set to zero. The units
(if any) depend on the meaning of each scalar according to the model that
produced them.
(Introduced in BodyBuilder version 3.5)
POWERS
ASCII
(L,N)
N labels of length L. Trajectories with labels matching those
in this list are to be treated as powers rather than translations. Since
powers are scalars rather than vectors, the value is held in the Z component
with X and Y both set to zero. See POWER_UNITS parameter for units.
(Introduced in BodyBuilder version 3.5)
FORCES
ASCII
(L,N)
N labels of length L. Trajectories with labels matching those
in this list are to be treated as forces rather than translations. See
FORCE_UNITS parameter for units.
(Introduced in BodyBuilder version 3.5)
MOMENTS
ASCII
(L,N)
N labels of length L. Trajectories with labels matching those
in this list are to be treated as moments rather than translations. See
MOMENT_UNITS parameter for units.
(Introduced in BodyBuilder version 3.5)
REACTIONS
ASCII
(L,N)
N labels of length L. These labels are used as a base name for identifying
three trajectories each that represent the force, moment and point components
of a reaction. The corresponding force trajectories have a ã.Fä
suffix, the moment trajectories a ã.Mä suffix and the point
trajectories a ã.Pä suffix. For example, ãLKNEEä
would correspond to ãLNKEE.Fä, ãLKNEE.Mä and ãLNKEE.Pä
trajectories. Note that force and moment trajectories listed in REACTIONS
should not appear in the FORCE and MOMENTS list.
(Introduced in BodyBuilder version 3.5)
POWER_UNITS
ASCII
(N)
Measurement units for power values, e.g. mW, cW, dW, W, daW, hW, kW
(Introduced in BodyBuilder version 3.5)
FORCE_UNITS
ASCII
(N)
Measurement units for force values, e.g. N, kN, hN, daN, dN, cN, mN
(Introduced in BodyBuilder version 3.5)
MOMENT_UNITS
ASCII
(N)
Measurement units for moment values, e.g. Nmm, Ncm, Ndm, Nm, Ndam,
Nhm, Nkm.
(Introduced in BodyBuilder version 3.5)
SEG: Group
Name
Type
Dimension
Usage
MARKER
_DIAMETER
real
scalar
Diameter of markers, or largest marker used, in POINT:UNITS. Note that,
when present, this should only be used as a guide since a single trial
may use markers of different sizes.
DATA_LIMITS
real
(3,2)
Lower and upper limits of reconstruction volume (in POINT:UNITS) for
SEG program to reconstruct a point
ACC_FACTOR
real
scalar
Maximum average acceleration (in POINT:UNITS/sec/sec) over 5 samples
for SEG program to start a new segment. Nominal value for gait analysis:
50mm/sec/sec.
NOISE_FACTOR
real
scalar
Maximum deviation from constant acceleration (in POINT:UNITS) over
5 points for SEG program to start new segment. Nominal value for
gait analysis: 10mm.
(only used in 370 version 1.x)
ANGLE_ERROR
_FACTOR
real
scalar
Factor multiplied to average calibration angular error of each camera
to determine "cone of reconstruction" for SEG program . Nominal value
for gait analysis: 2.0.
(only used in 370 version 1.x)
PREDICTION
_ERROR
real
scalar
Radius of extrapolated prediction volume (in POINT:UNITS) for trajectory
segment continuity in SEG program. Nominal value for gait analysis
with 25mm markers: 25mm.
RESIDUAL_ERROR _FACTOR
real
scalar
Controls inclusion of rays during reconstruction. Nominal value:
2.0
(New for 370 version 1.2)
MAX_NOISE
_FACTOR
real
scalar
Controls creation of new trajectories. Nominal value: 12
(New for 370 version 2.0)
INTERSECTION
_LIMIT
real
scalar
Limit for intersection of rays to form a reconstruction. Nominal
value: 7mm
(Introduced in 370 version 2.0)
FORCE_PLATFORM: Group
Name
Type
Dimension
Usage
USED
integer
scalar
Number of force plates used; L=0,1,2,3,or 4.
TYPE
integer
(N)
Transducer/output code for each plate (1..N);
1 = "AMTI" with c.o.p.+Mz
2 = "AMTI" with Mx,My,Mz
3 = Kistler with 8 channel output.
CORNERS
real
(3,4,N)
Corner locations for rectangular plates (1..N), measured in POINT:UNITS
in the reference coordinate system, ordered: xy, -xy,-x-y, x-y, with respect
to plate coordinate system. Indicates size of plate and provides
relative orientation of kinematic and force plate axes.
ORIGIN
real
(3,N)
Offsets, in POINT:UNITS, measured in plate coordinate system, relating
transducer positions to centre of top working surface.
Type 1: (1, ) and (2, ) are irrelevant, (3, ) is vertical distance
from transducer plane to top plate (-ve value)
Type 2: components of vector from transducer output origin to centre
of top plate. All components apply.
In VICON products, the opposite vector is used - from the centre of
the top plate to the plate origin.
Type 3: (1, ) is half inter-transducer distance in x-direction, (2,
) is half inter-transducer distance in y-direction, (3, ) is same distance
as types 2 and 3 (all values +ve)
CHANNEL
integer
(6,N), or
(8,N)
ADC channel assignments per plate for:
type 1 type 2 type 3
(1, ) Fx Fx Fx(1+2)
(2, ) Fy Fy Fx(3+4)
(3, ) Fz Fz Fy(4+1)
(4, ) Px Mx Fy(2+3)
(5, ) Py My Fz1
(6, ) Mz' Mz Fz2
(7, ) n/a n/a Fz3
(8, ) n/a n/a Fz4
Note that if mixed plate types are present and any of them are type 3 then the dimension is (8,) for all plates. If only type 1 and/or type 2 plates are used, the dimension may be (6,).
ZERO
integer
(2)
Range of analog sample numbers used to establish force plate baseline.
SUBJECTS: Group
Introduced in Vicon 370 version 2.5 and BodyBuilder version 3.0.
Name
Type
Dimension
Usage
IS_STATIC
integer
scalar
The value is 1 if the trial subjects were captured in a static pose
for the purposes of calibration, otherwise 0.
USES_PREFIXES
integer
scalar
The value is 1 if label prefixes are being used in this trial, otherwise
0. Used when labelling has not yet been performed. Note that the presence
of any non-blank LABEL_PREFIXES entries overrides this parameter.
USED
integer
scalar
The number of named subjects in the trial. May be 0 for trials where
specific subjects were not used or for subject calibrations.
NAMES
ASCII
(L,N)
N subject names of length L.
LABEL_PREFIXES
ASCII
(L,N)
N prefixes of length L. These identify prefixes attached to the trajectory
labels for each subject ordered as in NAMES. Each prefix is typically either
blank or the same as the subject name but with a colon Î:â
suffix.
MARKER_SETS
ASCII
(L,N)
N marker set names of length L. These identify the MKR filenames for
each subject ordered as in NAMES. Each subject may use a different marker
set. Note that the path is excluded from the filename.
DISPLAY_SETS
ASCII
(L,N)
N display set names of length L. These identify the active display
set within the marker set for each subject ordered as in NAMES. If blank,
the first display set should be used.
MODELS
ASCII
(L,N)
N marker set names of length L. These identify the model (usually .MOD)
filenames for each subject ordered as in NAMES. Each subject may use a
different model. Note that the path is excluded from the filename.
MODEL_PARAMS
ASCII
(L,N)
N marker set names of length L. These identify the model parameters
(usually .MP) filenames for each subject ordered as in NAMES. Each subject
will typically have their own model parameters. Note that the path is excluded
from the filename.
float ConvertDecToFloat(char bytes[4])
char p[4];
p[0] = bytes[2];
p[1] = bytes[3];
p[2] = bytes[0];
p[3] = bytes[1];
if (p[0] || p[1] || p[2] || p[3])
--p[3];
// adjust exponent
return *(float*)p;
}
void ConvertFloatToDec(float f, char* bytes)
char* p = (char*)&f;
bytes[0] = p[2];
bytes[1] = p[3];
bytes[2] = p[0];
bytes[3] = p[1];
if (bytes[0] || bytes[1] || bytes[2] || bytes[3])
++bytes[1];
// adjust exponent
The floating point format depends on the setting for processor
type (see Parameter Records section). Vicon 370 currently uses the DEC
format for compatibility with earlier Vicon VX systems. Vicon 370 versions
prior to B-1.2 incorrectly writes ANALOG:RATE as an integer.
The C3D data file format was developed by Andrew Dainis in 1987 as
a convenient and efficient means for storing 3D coordinate and analog
data, with all associated parameters, for a single measurement trial.
One design goal of the C3D file format was to provide the user a means
to easily examine, and if necessary modify, any parameter contained
in the file. This goal was achieved by providing the user with a program
(PRM) which interactively allows access to the parameters stored internaly
in binary format.
=============================================================================
TABLE OF CONTENTS
1. Parameter Manipulation Program PRM
2. C3D Data File Format
3. Parameter Access From Programs
=============================================================================
1. PARAMETER MANIPULATION PROGRAM PRM
1.1 INTRODUCTION
The PRM program provides the user a means of
accessing the parameters in
C3D and other ADTECH parameter files. It operates interactively through
a few
simple commands and provides output to terminal screen, printer, or
file. The
program allows the user to create, examine, change, and delete parameters
in any
file that contains data in the ADTECH parameter format, and acts as
a friendly
interface between the user and the parameters.
1.2 PARAMETER FORMAT
This section describes the format of the parameters
as displayed by the
PRM program. Internally to a file the parameters are stored in binary
format and
may be directly accessed using the techniques described in sections
2. and 3.
Each parameter is identified by a name, and
has a data type. A parameter
also has dimensions which describe how many pieces or elements of data
it can
hold, and optionally, a description. Additionally each parameter belongs
to a
parameter group having a group name and a group description. In listings
and
commands the group name and parameter name are separated by a colon
(:). By a
suitable choice of group and parameter names, and through the descriptions,
it
is possible to make the parameter functions largely self-explanatory.
The
ability to group parameters enables parameters pertaining to different
functions
to be included in the same file without risk of confusion.
A parameter or group name may consist of any
number of characters made up
from the letters A through Z, the numerals 0 through 9, and the underscore
character _ . The name should not start with a numeral or the
underscore
character. When a name is interpreted only the first six characters
are used.
Hence all group names and all names within a group should show at least
one
difference in the first six characters. The same names may be used
for two
parameters if they occur in different groups.
A parameter's type determines the type of data
that may be stored in it.
Four parameter types are used; integer, real, character, and byte.
These data
types correspond to the conventional meaning of the terms in computer
programming. An integer is a 16-bit signed number between -32768 and
+32767, a
real number is one containing a decimal point or written in scientific
exponential representation, a character is a literal symbol such as
a letter
entered from the keyboard, and a byte data location can contain a 8-bit
signed
integer in the range -128 to +127.
The dimensions of a parameter define how many
elements of the appropriate
type may be stored in that parameter. The use of the term dimensions
also
follows normal programming conventions. If a parameter has no dimensions,
then
it may only hold one value of its data type. If it has one dimension
it is
presented in the form such as PARM(4) where the 4 indicates
that the parameter
called PARM is capable of holding four values. Examples of two- and
three-
dimensional parameter arrays are PARMA(4,5) and PARMB(3,5,7). The first
example
has 4 x 5 = 20 elements, and the second parameter holds 3 x 5 x 7 =
105 entries.
The content of any parameter element may be selectively examined and
modified
by use of the PRM program.
The description part of a group or parameter
definition simply provides
information as to the function of the particular group or parameter,
and is
included for informational purposes only.
1.3 RUNNING THE PROGRAM
1.3.1 Starting the PRM Program
The Parameter Manipulation Program is started by entering
PRM <file name>
from the keyboard in response to the operating system prompt. The screen
will
clear, the program title will be displayed, and the requested file
will be
opened. If no file name is provided, the program will request the input
of a
file name.
1.3.2 Accessing the Parameters
If the named file is found, it is opened and
the program first tests to
determine that the file does contain parameter data. If the format
is valid, the
data are read into memory and become available for manipulation. If
the file
does not contain parameter data a message to that effect is output
to the
terminal screen and the user is prompted for another file name. If
the named
file cannot be opened for any reason, a new file is opened in preparation
for
creating a new set of parameters and a new file message
is displayed on the
terminal screen. The user then may proceed to create parameter groups
and
parameters as described in the remainder of this chapter. Once the
program is
ready to accept parameter manipulation commands, the prompt symbol
? will be
displayed. If a mistake was made in entering the file name and the
user does not
wish to create a new file, the abort command AB(ort) should be entered
in
response to the ? prompt. In this circumstance the program will ask
for another
file name.
When an existing file is opened, the program
first lists the existing
parameter groups before displaying the ? prompt.
1.3.3 Terminating the Program
Either of the commands ABort or EXit will terminate
the PRM program. The
ABort command will cause the program to exit without making any changes
to the
input parameter file, whereas the EXit command will cause the input
file to be
updated with the changes entered during this session.
1.4 COMMAND DESCRIPTION
The PRM program responds to eight commands:
CREATE, DELETE, LIST,
PRINT, WRITE, CHANGE, ABORT, and EXIT. All commands except CREATE may
be abbreviated to their first letter. The shortest abbreviation allowed
for
CREATE is CR. The CREATE and DELETE commands will be described first.
However, the user will very rarely need to use these two commands since
the
modification of existing parameter files, or of copies of existing
files,
provides a more efficient technique for obtaining new files. The creation
of a
new parameter file must be done very carefully because errors in parameter
names
or dimensions will cause programs to reject the parameter data. Occasionally
the
CREATE and DELETE facilities may be useful for changing the dimensions
or
description of a parameter, or replacing an incorrectly created parameter.
In the following command descriptions, di refers
to the ith dimension of
a parameter (for instance, the 7 in CAM_CHAN (7) ).
1.4.1 Create (CR)
1.4.1.1 Group
To create a new parameter group, the command is
CReate group_name:/description
The group called group_name is created, and
with it is associated a
description. If a group is being created, the ':' must be specified.
Also, the
slash character '/' must be used to separate the description from the
rest of
the command.
1.4.1.2 Parameter
To create a parameter within an existing group, use the command
CReate {group_name:}parameter {(d1, d2,...)},type/description
If a group name is not placed in front of a
parameter name, the parameter
will be created in the default group. The default group is the one
whose name
was last specified in any command. If a group name is included before
the
parameter name then the parameter is created in the specified group.
A parameter may have up to seven dimensions,
but normally none, one, or
two are used. If no dimension is defined then that parameter can only
hold one
element. The parameter type must be specified as a single character
from the
list of four; I, R, C, and B where I denotes Integer, R denotes Real,
C
denotes Character, and B denotes Byte. The slash / must precede the
description
part of the definition.
When a parameter is created, it is filled with
default values. For
numerical parameters (those of type real, integer or byte) the default
value is
zero. For the character type of parameter the default entry in all
locations is
the space ' ' character. Once a parameter or group is created, its
name,
dimensions, or description may only be changed by deletion and re-creation.
There are no restrictions on the length of
group or parameter names, which
must be made up from the letters A - Z, the numerals 0 - 9, and the
underscore
character _ . A name should not start with a numeral or
_ . Only the first six
characters of a name are referenced when a name is interpreted. Therefore
no two
names of parameters in the same group should be identical in all first
six
characters. Parameters may only have the same names if they belong
to different
groups.
1.4.2 Delete (D)
Groups and parameters may be deleted. A group
may be deleted only after
all parameters within it have been deleted. A parameter may be deleted
if it is
not locked by the program that created it. A locked parameter (identified
by and
asterisk (*) in front of its description) may also not be modified
by the CHANGE
command. The delete command has the format
Delete group_name:
or
Delete group_name:parameter_name
Note that a group name must always be used
when a parameter is being
deleted. Also, any parameter or group name may be abbreviated, even
down to one
letter. However, if the abbreviation can refer to more than one name,
action may
be taken on the wrong parameter.
1.4.3 List (L), Write (W), or Print (P)
The only difference between these commands
is the output device to which
the information is sent. The List command results in output to the
terminal from
which the command was entered, the Write command writes the output
to a file
named LISTPAR.DAT, and the Print command additionally sends the LISTPAR.DAT
file
to the system printer. Note that data are written to the output file
until
either the EXit or ABort command is given, at which point the file
is closed
(and sent to the printer if the Print command was used).
1.4.3.1 Groups
A listing of all groups may be obtained by the command
L :
where the : symbolically denotes groups. The space between the command
and the
colon is required. The parameter names, dimensions and descriptions
contained
in any group may be listed by the command
L group_name:
and an L without any group name will list all of the parameter names
in the
current default group. It should be noted that any time a group name
is used,
that group becomes the current default group. Also, when a group is
listed the
content of any parameter that has a single element is also automatically
listed.
1.4.3.2 Parameters
This output commands has the general syntax:
List {group _name:}parameter_name {(d1 {, d2,..})}
If the group name is omitted, then the current default group name is
used. A
parameter name must be specified, and the dimensions are optional.
Abbreviations
for group and parameter file names may be used. If no dimensions are
specified,
the values of all elements of the parameter are listed. By use of entries
within
the dimension parentheses, any subset of elements of the parameter
may be
listed. As an example, consider a parameter that was created with the
command
CR COORD(3,20),R/Reference point coordinates
The organization of this parameter may be thought of as consisting of
60 storage
locations arranged in an array that has three rows and 20 columns.
Each location
can store a real (floating point) number. The command
L COORD
will cause the PRM program to list all values in COORD starting with
the value
stored in location (1,1), followed by (2,1), (3,1), (1,2), (2,2), (3,2),
(1,3),.... , (3,19), (1,20), (2,20), (3,20), i.e., the first dimension
is varied
most rapidly, followed by the second dimension, and so on. The command
L CO(2,15)
will list the value stored in the second row and the 15th column. If
a dimension
is omitted, all the elements for that dimension will be listed, i.e.,
the
command
L COORD(,15)
will list the elements (1,15), (2,15), and (3,15), whereas the command
L COORD(3,)
will display the values in (3,1), (3,2),...., (3,20). The command L
COORD(,)
is equivalent to L COORD . The above example illustrates how program
PRM
provides a simple and flexible facility for selecting parameter data
for display
or modification.
1.4.4 Change (C)
1.4.4.1 Groups
The Change command may be applied to an entire group as in
Change group_name:
to have the program prompt for the modification of all single element
parameters
contained in the group.
1.4.4.2 Parameters
In its most general form the change command has the format
Change {group_name:}parameter_name {(d1, {d2, ...})}
If a group name is not given, the current default
group name is assumed.
The rules for accessing the elements of a dimensioned parameter are
the same as
those for the LIST command, i.e., all, some, or one of the elements
of a
parameter may be selected for modification. After a change command
is entered,
each element is listed on the terminal with its current value. The
user is then
prompted for the entry of a new value. Pressing just the <ENTER>
key leaves
the value in that particular element unchanged. If the user wishes
to exit from
the change mode without completing the list specified in the change
command,
then the PRM prompt symbol ? should be entered.
Some parameters are locked by their creating
programs in order to protect
the data from modifications which may cause succeeding programs to
function
incorrectly. A locked parameter can be recognized by an asterisk preceding
its
description, and any attempt to change or delete it results in a message
stating
that it is locked.
The first dimension of a parameter which has
a character type determines
how long the lines are for entering characters. For example, a character
parameter with dimensions (30,5) holds five lines, with each line having
room
for 30 characters. A command to change or list the third line would
specify the
dimensions (,3) . Actually for character parameters, the first dimension
may be
omitted altogether, and the dimension may be specified as just (3).
NOTE: To clear a character line of any text, enter a single exclamation
mark
in response to the prompt for input for that line.
=============================================================================
2. C3D DATA FILE FORMAT
2.1 FILE STRUCTURE
The coordinate (and analog) data in .C3D files are
written in 16-bit
integer (INTEGER*2) format, or optionally floating point (REAL*4) format,
consisting of records that are 512 bytes long. The files have three
sections.
The first section consists of just one header record and contains a
few
parameters as described in Section 2.2. The second section starts at
record
number 2 and contains parameters in ADTECH format. This section is
variable in
length but is typically about 10 records long. The rest of the file
contains
the 3D point coordinate data, and analog data if analog data were available
when the .C3D file was created. Standard format of coordinate and analog
data
is in the integer format. However, the facility for the data to be
written
in REAL*4 format is also available for the storing of filtered data
where the
integer form may not provide sufficient precision.
2.2 HEADER RECORD
Although all parameters of interest are contained
in the parameter
section, a few essential parameters necessary for accessing the data
in the
file are repeated in the header record in simple form. The parameters
in this
record are useful if one does not wish to use the parameter subroutines
required to access the quantities written in parameter format. The
ADTECH
parameter format allows for very convenient interactive user access,
but is
more complex from the programming aspect. The first few words of the
header
record are utilized to store the abbreviated parameter data, and the
rest of
the header record contains zeros unless time event data have been written
to
the data file. The parameter values stored in the header record are
as listed
in Table 2.1. The 16-bit words hold integer values unless otherwise
noted.
WORD
CONTENTS
-----------------------------------------------------------------------------
1
Byte 1: number of 1st parameter record
Byte 2: must contain 80(decimal)
2 Number of 3D points
3 Number of analog channels for which data is stored
4 Number of first video frame in .C3D file
5 Number of last video frame in .C3D file
6 Maximum interpolation gap allowed (in frames)
7,8
(REAL*4) Scale factor for converting integer 3D data to
reference system units. If negative, 3D data is already in
REAL*4 format.
9 Starting record number for 3D point and analog data
10 Number of analog frames / video frame
11,12 (REAL*4) Video frame rate (Hz)
13-149 Currently not used
150 12345(decimal) keyword to identify presence of event data
151 Number of defined time events -- maximum of 18
152 Not used
153-188 (REAL*4) Event times (in seconds) -- maximum of 18
189-198 (BYTE*1) Event display switches (0=ON, 1=OFF)
199-234 Event labels. 4 characters for each event.
-----------------------------------------------------------------------------
Table 2.1 --
Contents of first record of .C3D file.
2.3 PARAMETER RECORDS
The parameter section is written in ADTECH parameter
format which
allows the user to interactively access the parameters with the program
PRM.
Programmers may access the parameters through the FORTRAN library
PRMLIB
or write programs to access the parameter data directly. Chapter 3
provides
instructions for calling the subroutines in the PRMLIB library, and
the rest
of this section describes in detail the ADTECH parameter format for
those
that want to access the parameters the hard way.
The first two bytes of the first parameter record
are either not used,
or form the first two bytes of the file. If they are the first
two bytes of
the file (not the case for C3D files), then byte 1 contains the number
of the
first parameter record, and byte 2 contains 80 (decimal).
Byte 3 of the first parameter record contains the
number of parameter
records, and byte 4 contains 85(decimal) + processor_type. Processor_type
may
have the value 1, 2, or 3, and is defined in Section 3.1. The actual
parameter
data start at byte 5 of the first parameter record.
Within the parameter records, the data belonging
to groups and
parameters are stored in no particular order, and are located by searching
through the total data block. The storage unit is the byte.
Group data are stored in the following format:
-------------------------------------------------------------------------------
Byte 1
Number (n) of characters in group name
Byte 2 Group ID number (negative)
Bytes 3 --> 3 + n - 1 Group name
Bytes 3 + n , 3 + n + 1 (2-byte integer)
offset in bytes pointing to
start of next group/parameter
Byte 3 + n + 2 Number (m) of characters in group description
Bytes 3 + n + 3 --> 3 + n + 3 + m - 1
Group description
Parameter data are stored in the following format:
-------------------------------------------------------------------------------
Byte 1
Number (n) of characters in parameter name
Byte 2 Group number (positive) to which parameter belongs
Bytes 3 --> 3 + n + 1 Parameter name
Bytes 3 + n , 3 + n + 1 (2-byte integer)
offset in bytes pointing to
start of next group/parameter
Byte 3 + n + 2
Length in bytes of each data element
-1 for Character
1 for Byte
2 for Integer*2
4 for Real*4
Byte 3 + n + 3
Number (d) of dimensions of the parameter (max. = 7)
d = 0 if the parameter is undimensioned.
Bytes 3 + n + 4 --> 3 + n + 4 + d - 1 Parameter dimensions
Byte 3 + n + 4 + d --> 3 + n + 4 + d + t - 1
The parameter data. t = product of all dimensions
and element length
Byte 3 + n + 4 + d + t Number (m) of characters in description
Bytes 3 + n + 4 + d + t + 1 --> 3 + n + 4 +
d + t + 1 + m - 1 Parameter
description
The PRM program responds to the command SH, which
will dump all
parameter records in byte format, and their ASCII equivalent, to the
screen.
2.4 DATA RECORDS
The 3D coordinate and analog data are written frame-sequentially
starting at the beginning of the first data record. The data are packed
into
records such that frames may cross record boundaries. The 3D coordinate
data
are normally stored in 16-bit integer format and must be multiplied
by the
POINT:SCALE factor to generate values expressed in the external (reference
coordinate system) measurement units. If the data is stored in floating
point
format (REAL*4), then the scale factor has already been applied and
it is set
to be negative.
Each 3D point is described by four words. If the
data is stored in
integer form, these 16-bit words contain the following:
WORD
CONTENTS
-----------------------------------------------------------------------------
1 X-coordinate of point / scale factor
2 Y-coordinate of point / scale factor
3 Z-coordinate of point / scale factor
4
Byte 1: cameras that measured marker (1 bit for each
camera)
Byte 2: average residual for point measurement
/ scale factor
-----------------------------------------------------------------------------
Table 2.2 -- 3D point data contents.
The video data for frame
one are stored first, followed by one or more
analog "frames" if analog data are present. If the analog data rate
was the
same as the video frame rate then only one analog frame will follow
each video
frame. If analog rate was twice the video rate, then two analog frames
will
follow the video frame, etc. Both the video and analog data will always
be in
the same format, .i.e., INTEGER*2 or REAL*4.
NOTES:
In Byte 1 of Word 4, bits are set corresponding
to which cameras
contributed to the point's measurement.
Bit 0 refers to the first
camera, bit 1 the second, etc.
If a point was invalid in a frame (not observed
by at least two
cameras), its 4th word will be set to
-1, and the X, Y, and Z
coordinates will be set to zero. For
points that were interpolated,
the residual is set identically to zero.
In an integer file the coordinates and residuals
are recorded in
internal units, and must be multiplied
by the scaling factor in
POINT:SCALE to obtain reference coordinate
system units.
The analog data are stored in the same order
as in the raw data file,
i.e., if the analog frame rate was higher
than the video frame rate,
the order through the channels is repeated
as many times as is
appropriate. The first word after the
end of the analog data is the X-
coordinate of the first point in the
next frame.
If the data is stored in floating point format,
the X, Y, and Z
coordinates have already been multiplied
by the scale factor. The 4th
word is the normal 4th word integer
value stored as a floating point
number. To extract its data, it should
be converted to integer, divided
into high and low bytes, and the low
byte must be multiplied by the
scale factor to obtain the correct residual
value.
===============================================================================
3. PARAMETER ACCESS FROM PROGRAMS
3.1 PARAMETERS IN FILES
The location of parameter records in any file is specified as follows:
1. Byte 1 of the first record of the file must contain the record
number
of the first parameter record in the file.
2. Byte 2 of the first record of the file must contain 80(decimal).
3. Byte 3 of the first parameter record must contain the number
of
parameter records to follow.
4. Byte 4 of the first parameter record must contain 83(decimal) + data_type.
Data_type is an integer having a value 1, 2, or 3 and designates the
computer
system type the file was created on, or is formatted for. Recognized
values
are;
1 = PC-DOS
2 = DEC (VAX , PDP-11)
3 = MIPS processor (SGI , SUN)
The library routine GPREC checks for the above four conditions when
parameter
data is read from a file, and the parameter output subroutine OUTPT
ensures
that the four bytes described above are written to the output file.
3.2 CALLING PROGRAM REQUIREMENTS
The data stored in ADTECH parameter format may be
accessed from user
programs by the use of calls to subroutines and functions contained
in the
parameter library PRMLIB. The library is provided in Microsoft 16-bit
FORTRAN
format.
The routines operate on the entire parameter
data set which must be
first read into memory by the function GPREC. Once in memory, parameters
may
be created, deleted, read, or modified. At conclusion, the entire parameter
set may be output to a file by the subroutine OUTPT.
In order to use the library routines, the calling
program or subprogram
must contain the following statements:
PARAMETER (LMSIZE=5120)
INTEGER*1 LM(LMSIZE)
INTEGER*2 RECL,LBOT,LTOP
COMMON /PAR1/LBOT,RECL
RECL=512
LTOP=LMSIZE
The array LM must be large enough to store the entire
parameter set,
i.e. LMSIZE must be at least 512 * number of parameter records. An
LMSIZE of
5120 bytes is adequate for most .C3D files.
Before the library routines can be used, the
file containing the
parameter data must be opened. In this chapter the variable LUN will
be used
for the data file logical unit number, and LCT will be used for the
terminal
output logical unit number. Normally they would be assigned in the
calling
program as for example in
LUN=2
LCT=5
In the following both LUN and LCT can be constants or variables.
The command to open the file will be similar to the following;
OPEN (UNIT=LUN,FILE='file_name',STATUS='OLD',
* ACCESS='DIRECT',RECL=512,ERR=800)
If the file is opened successfully, the routines described in the next
section can then be used to access the parameters.
3.3 SUBROUTINES AND FUNCTIONS
3.3.1 Read in all parameters
FUNCTION GPREC (LUN,LM,LTOP,ISTREC,INTYP)
This function reads in all parameter data into the
array LM and
converts it to the current processor type
(see Section 3.1). GPREC
must be declared as an INTEGER*2 function
and it returns:
GPREC = 0
if the read is successful
-1 if there was a file read error
-2 if parameter records were
not found in the file
-3 if LTOP was exceeded (LM was
too small)
ISTREC is output, and returns the record number in
the file where the
parameters started. INTYP is also output and
contains either 1, 2, or
3 specifying which processor type the file
was formatted for. After
the data is read in the input file may be
closed.
3.3.2 Write parameters to file
SUBROUTINE OUTPT (LUN,LM,ISTREC,IRLAST,OUTYP)
Writes the full parameter set to logical unit LUN.
The file must have
previously been opened as a direct access
file. ISTREC is input and
specifies the record number where the first
parameter record is to be
written. This value will be stored in the
first byte of the data file
as a pointer to the start of the parameter
data. IRLAST returns the
record number of the last parameter record
in the file, i.e., the
number of parameter records written is given
by IRLAST - ISTREC + 1.
OUTYP is input to the routine and specifies
in what processor format
type the parameters are to be written. This
parameter may have the
values 1, 2, or 3 as described in Section
3.1.
3.3.3 Create a parameter group
SUBROUTINE DEFG (GNAME,DESCR,IFG,LM,LTOP)
Creates a parameter group whose name is in GNAME.
GNAME may be a
character string, or an INTEGER*1 or LOGICAL*1
array terminated with a
null byte. Similarly, a group description
is specified as a character
string or byte array in DESCR. The variable
IFG is output and contains
the (negative) internal group ID number assigned
to this group. An
example of a call might be
CALL DEFG ('POINT','Point parameters',IFG,LM,LTOP)
Note that in Microsoft FORTRAN, the 'C' character
must be appended to
literal strings, as in 'POINT'C .
3.3.4 Create a parameter
SUBROUTINE DEFP (PNAME,TYP,GNAME,DESCR,LM,LTOP)
A parameter with the name contained in PNAME
is created in an existing
group having the name GNAME. TYP
is one of the single character
literals 'I','R','B', or 'C' specifying
that the parameter is of type
Integer (INTEGER*2), Real (REAL*4),
Byte (INTEGER*1 or LOGICAL*1), or
Character, and DESCR contains a description
string. PNAME may specify
dimensions which are interpreted as
described in Chapter 8 of the
User's Manual. Example:
CALL DEFP ('NN(3,4)','I','GRP1',
*
'Descriptive text',LM,LTOP)
This call would create a parameter named NN
of type integer, and having
dimensions (3,4). If it is desired to
use a variable for one or more of
the dimensions, then the subroutine
ENCN described in Section 3.3.8
must first be used to encode the dimensions
into the parameter name
string.
3.3.5 Delete a Group
SUBROUTINE DELG (GNAME,LM,LTOP)
Deletes the group entry for GNAME. All the
parameters in the group must
have been first deleted. e.g.,
CALL DELG ('GRP1',LM,LTOP)
3.3.6 Delete a Parameter
SUBROUTINE DELP (GNAME,PNAME,LM,LTOP)
Deletes the parameter named PNAME in the group
GNAME and reclaims
space, e.g.,
CALL DELP ('GRP1','NN',LM,LTOP)
3.3.7 Read or write parameters
SUBROUTINE PRPAR (LCT,PNAME,GNAME,IFN,ADDR,LM,LTOP,MAXD)
This subroutine performs the following functions depending on
the input value
of IFN.
IFN
FUNCTION
---------------------------------------------------------------------------
0 The contents of the parameter specified in PNAME are
listed to unit
LCT.
1 Causes a prompt for the interactive modification of the
parameter(s)
PNAME via logical unit LCT.
2 The parameter values specified by PNAME are extracted
from the
parameter set and stored in the variable
ADDR. MAXD specifies in bytes
the maximum amount of data that is allowed
to be read into ADDR (i.e.,
the size of ADDR). If the data specified
in PNAME is larger than MAXD,
then no action is taken and MAXD is
returned as -1. Otherwise MAXD is
returned as the number of bytes actually
read in. If the parameter
cannot be found MAXD is returned as
zero. In an error condition a
message is written to unit LCT.
3 The data starting at variable ADDR is stored in the parameter
PNAME.
MAXD should be set to the number of
bytes expected to be stored. MAXD
is returned as 0 if there was room for
all data, and returned as the
number of bytes actually stored if there
was not enough room. If the
parameter was not found MAXD is returned
as -1.
-3 Data is stored as for IFN = 3, but the parameter is locked
to prevent
it from being modified interactively.
Examples:
CALL PRPAR (5,'NN(,2)','GRP1',0,ADDR,LM,LTOP,MAXD)
would list the values of NN(1,2), NN(2,2),
and NN(3,2) on the logical
unit 5.
CALL PRPAR (5,'NN','GRP1',2,ADDR,LM,LTOP,MAXD)
copies the contents of parameter NN to
memory starting at the address
occupied by the variable ADDR. Note
that no checks for correct variable
lengths are performed other than through
the MAXD variable. Also MAXD
must be a variable and not a constant.
CALL PRPAR (5,'NN(2,4)','GRP1',3,JJ,LM,LTOP,MAXD)
causes the value in JJ to be stored in the
parameter location NN(2,4).
3.3.8 Encode dimensions into a parameter name
SUBROUTINE ENCN (NAMIN,NAMOUT,NCHR,NDIM,IDIM)
If it is wished to use variables rather
than constants to specify
dimensions in a parameter name, use
this subroutine to form the
parameter name before using it in
DEFP or PRPAR.
ENCN encodes the first NDIM values in the variable
array IDIM and adds
the string to NAMIN to produce NAMOUT,
which can then be used as PNAME
in the subroutine calls, e.g., the call
CALL ENCN ('INNAME',NAMOUT,NCHR,NDIM,IDIM)
where NDIM = 3, IDIM(1) = 3, IDIM(2) = 6, IDIM(3)
= 4, will result in
the output of a string array NAMOUT
containing 'INNAME (3,6,4)'
A zero value in IDIM will omit the value for
that dimension. For
example, if IDIM(2) was set to
zero in the example, the NAMOUT would
contain the string 'INNAME (3,,4)'
3.3.9 Create new parameter block
SUBROUTINE START (LM,LTOP)
Call this subroutine to initialize a new parameter
block, i.e., if you
wish to create a new parameter file
without using GPREC to read in an
existing parameter block.
3.3.10 Convert data between different processor systems
These subroutines are not directly related
to accessing parameter data,
but are included because they may be useful in converting data
between the
different computer system types.
SUBROUTINE RCONV (INTYP,OUTYP,RR,N)
RR is an array containing N floating point
(REAL*4) numbers to be
converted from INTYP to OUTYP. INTYP
and OUTYP may have values chosen
from 1, 2, or 3 as described in Section
3.1.
SUBROUTINE ICONV (INTYP,OUTYP,IR,N)
IR is an array containing N integer (INTEGER*2) numbers to be
converted from
INTYP to OUTYP. INTYP and OUTYP may have values chosen from 1,
2, or 3 as
described in Section 3.1. The integer formats for type 1 and
2 processors are
identical.
3.4 NOTES
1. All of the subroutines in PRMLIB have
been compiled with the /4I2
switch for Microsoft
FORTRAN. This switch causes all integers to be
interpreted as INTEGER*2
rather than INTEGER*4 which is the default
for the compiler.
All integer variable arguments passed to the
subroutines must be
declared as INTEGER*2. An alternative technique
is to compile the
calling program also with the switch.
2. PNAME may contain partial dimensions in
order to access a subset of the
parameters stored
in PNAME, and name and group abbreviations may be
used. The program
PRM is simply an implementation of the subroutines
described in the last
section.
3. If an error condition results, then a message
is output to unit LCT. If
LCT = 0, then no error
messages are generated.
Date: Tue, 6 Oct 1998 08:27:49 -0400
From: Jonathan Attias <jonathan.attias@metrics.co.uk>
To: 'Alan R Morris' <morrisa@ecf.utoronto.ca>
Cc: Geoff haw <geoff.shaw@metrics.co.uk>,
Martin Lyster <martin.lyster@metrics.co.uk>,
Warren Lester <warren.lester@metrics.co.uk>
Subject: RE: C3D format query!
Hello Alan
Prior to version 2.5, unlabelled trajectories did not get saved in the
C3D file unless you explicitly used a command to assign (arbitrary)
numerical labels to them. This means that those trajectories were
permanently lost.
In version 2.5, this is more serious because of automatic processing.
If
the automatic labeller fails, for any reason, to label all trajectories
then using the old scheme would result in unrecoverably lost data and
a
useless trial. You would have to reconstruct and label it again and
tidy
it up manually before saving. So now, all trajectories are saved unless
you explicitly use a command to delete unlabelled (or other unwanted)
trajectories. This allows you to go back and tidy up any trials that
were not processed correctly in their entirety. There are also other
reasons for changing the storage algorithm, related to multiple subject
support, including multiple MKR files in a single trial.
Another difference is that, prior to version 2.5, trajectories happened
to always be written in the order specified in the MKR file. However,
the ordering was never guaranteed and you could easily find yourself
with an equivalent C3D file where the trajectories appear in a different
order based on a different, but equivalent, MKR file. This is because
different people like to manually label in different ways. For example,
many people like to start at the top and work down whereas I like to
label one limb at a time so I might use a different MKR file to reflect
that.
The point is that the ordering of trajectories in a C3D file is
completely arbitrary and should never be relied upon; the corresponding
trajectory labels should always be taken from the parameters section
of
the C3D file.
This has tripped up a few people like yourselves who have written custom
software that made assumptions about the storage mechanism. To solve
this, we introduced a new user preference feature in version 2.6 to
force the trajectories to be saved in the order specified by the MKR
file. It uses rules such as outputting trajectories assigned to subjects
first (one subject at a time) followed by trajectories unassigned to
particular subjects. One disadvantage of using this option is that
your
files can become quite large, filled with blank trajectories (as
before). You will have to contact Geoff if you need to get hold of
this
version.
In addition, you should modify your code to remove the assumption that
there will only be 10 trajectories in the file. You already read in
the
actual number of trajectories so this shouldn't be hard.
Hope this has provided you with the answers you need.
Regards,
Jonathan Attias
Software Development Manager
Oxford Metrics Limited
Date: Wed, 7 Oct 1998 04:10:07 -0400
From: Jonathan Attias <jonathan.attias@metrics.co.uk>
To: 'Alan R Morris' <morrisa@ecf.utoronto.ca>
Subject: RE: Update on previous message!
Alan
Regarding the parameters, it is easy to get confused. The record count
you are referring to (byte 3 of the parameter section in the file)
actually indicates the number of 512 byte 'file' records allocated
to
the entire parameters section. Because of a mis-interpretation of this
value, Vicon software prior to version 2.6 sometimes writes an incorrect
value in here so it should not be relied upon anyway.
There is no count stored for the number of parameters in each group
and,
according to the original C3D specification, all group and parameter
records can appear in any order. This means that parameters could even
appear before the group that they are in. In practice, Vicon always
writes the data out with a group followed by all of its parameters
before going on to the next group.
The way to relate parameters to groups is by use of the group ID number.
Our documentation is rather unclear on this so you would be better
referring to the AMASS documentation from Andy Dainis (part 11, section
2.3 of May 5, 1994 manual set). Group records have unique ID numbers
within the file which are stored as a negative value in byte 2. All
parameters belonging to the group store the same ID as a positive value,
also in byte 2. Having found the group you are interested in, you need
to search through all the other records to find the corresponding
parameters with a matching ID. The end of the parameter data section
is
found when the number of characters for the group/parameter name (byte
1) is zero. One thing to note is that you can't rely on the group ID
being the same for the same group in different files, or even successive
saves of the same file, though in practice, Vicon tends to use the
same
numbers.
Best of luck with this!
Regards,
Jonathan Attias
Software Development Manager
Oxford Metrics Limited
I agree with the comments summarized by Gerome Garthwaite, that the
C3D parameter format is rather tricky. This design
was necessitated by the requirement of flexibility and ease of access
to the user. With respect to the recent postings I
would like to point out a number of things that might prove to
be useful.
1) All parameters may be accessed and modifed interactively by use of
the PRM program that I provide on the anonymous
NIH ftp site ftp://bmli1.cc.nih.gov/pub/c3d_files/. The program will
acces PC-Intel, DEC, and SGI written data files, and
also indicate which data type they are.
2) AMASS software transparently handles C3D files from the three CPU
types (PC-Intel, DEC, SGI etc.), but Oxford
Metrics software does not (it still recognizes only DEC). This has
been the source of considerable confusion. The
differences are due to the the way floating point (real*4) numbers
are stored by each type of hardware.
3) A complete library of object code is available at the ftp site, with
full documentation, for manipulating/creating
parameters. However, it is 16-bit MS Fortran.
4) PRM will allow one to build a parameter section from scratch, but
I do not recommend it. It is too easy to make a
mistake. It is better to modify an existing parameter section using
PRM or the library.
5) To create a C3D file one does not necessarily have to know how to
access the parameter section. You can take the
parameter block from any existing file and just insert it into the
new file. You can use PRM to make any modifications to
the parameter section before or after. The header record and data records
are quite easy to write.
As the originator, and by default "keeper", of the C3D file format,
I will be happy to answer questions of interpetation,
etc., or receive comments regarding the file format.
Andy Dainis
adainis@cfw.com