A C3D File Format update is planned

[Edmund Cramp]

I have recently made some modifications to the C3D.ORG website to give it a responsive design that works better on both desktop and mobile devices. I am now working to bring the C3D format documentation and on-line help pages up to date to describe modern C3D usage. As part of the website update I requested and received sample C3D files from several companies in the biomechanics world and after looking at the contents of the C3D files that I received, I think that it's time to update the C3D format definition and documentation.

My plan is to document two simple extensions to the C3D format that will be completely transparent to any existing application that complies with the C3D format definition. The new extensions and an updated C3D manual will be available on-line in about a month once the manual is complete.

The extensions that I am working on define a small modification to the C3D standard that will improve the ability to generate clean C3D files containing accurate data that is easily stored, shared, and accessed. I plan to document a method of storing multiple parameter sections and additional data sections that can store processed data in the C3D format efficiently without disturbing the existing data, allowing manufacturers to transition to the new format definition if they wish, without causing any compatibility issues for current C3D users.

Because the new c3d.org web site is cookie-free, does not track any visitors, or record any user's access to maintain the C3D format as vendor neutral, I am posting this announcement on Biomch-L to alert anyone working with the C3D format about some proposed changes. I would welcome any questions or comments.

[Tim Bhatnagar]

Re: A C3D File Format update is planned

The extensions that I am working on define a small modification to the C3D standard that will improve the ability to generate clean C3D files containing accurate data that is easily stored, shared, and accessed.

Hi Edmund,

Thanks for your work on this! Regarding the quote above - can you describe what you think the effects will be from a user's perspective? It's great that you are ensuring that there will no disruptions to processes using C3D's, but what do you think will improve?

Thanks!

Tim Bhatnagar

[Edmund Cramp]

Re: A C3D File Format update is planned

The plan is that any existing user with any current application will not see any changes in the C3D data or accessibility although C3D files may get a little larger. In future, applications and users who understand the extension, will be able to store a lot more data, including IMU data and related parameters, in a way that blends with existing data.

I also want to address the issues that have arisen as floating-point has become the default storage format, leading manufacturers to fail to store the parameters describing the data - this is essentially a failure to understand the format so I clearly need to explain the format details a little better.

[Ognjen Toholj]

Re: A C3D File Format update is planned

Hi Edmund,
Thanks for your work on the c3d file format. I just want to see if you had any c3d samples from animation companies. Our company mostly deals with mocap vendors and we noticed that there are so many different ways how software reads and writes c3d that is almost impossible to read them all in proper way. Let me know if you ever need any extreme examples of c3d data.

[Edmund Cramp]

Re: A C3D File Format update is planned

There are some sample files available on the C3D web site - https://www.c3d.org/sampledata.html but nothing generated by an animation company. Typically animation companies are reading C3D file created by a motion capture vendor as far as I know. If anyone has any animation C3D file that they would like to make available I would be glad to add them to the site.

If you have a C3D file that you can not read and would like to send me a copy then I might be able to tell you where the problems are. Typically I see problems with animation vendors where people have scaled the data in meters or centimeters instead of millimeters.

[Edmund Cramp]

Re: A C3D File Format update is planned

I have posted the revised C3D User Guide on the C3D web site, it is now available as on-line help, as a downloadable and printable PDF file, and as a Microsoft compiled help (CHM) file - all can be downloaded from the web site. Each version will display a date on the first documentation page so that users can verify that they are up to date.

The most significant changes involve support for UTF-8 encoding and more than 255 analog data channels for IMU support - a large number of edits have been made to bring the document up to date with modern usage and correct a small number of documentation errors in the older manual. Full details of the changes are documented in the documentation Revision History.

[Edmund Cramp]

Re: A C3D File Format update has been completed

The C3D web site has copies of the current C3D format description, downloadable and on-line - there have been a couple of significant updates to the C3D description that may affect applications that people have written:

1. The original description documented the C3D file frame count (POINT:FRAMES) as a 16-bit signed integer count, this was changed in the early 2000's to describe the count as an unsigned integer. However the design of the C3D file format has always permitted this to be stored as a floating point value which removes all integer limits from the frame count. The POINT:FRAMES parameter is now described as potentially either an unsigned 16-bit integer or a floating point value - this will make life much easier in future.
2. The 2004 description incorrectly documented that the C3D file header words storing the "first frame" and "last frame" referred to the C3D file frame numbers but after re-reading the original documentation written I realized that this referred to the frame count of the SEG file that created the C3D file, not the C3D file frame numbers. This makes a lot more sense and the documentation has been updated to correct this which greatly simplifies life although there may be issues for some current applications if the header frame numbers are not updated if the C3D file is edited in a way that changes the frame numbers.
3. The documentation describes how UTF-8 encoding can be applied to the C3D file format in a way that will maintain compatibility for all applications but allow users with non-ASCII languages to use their own character sets to describe markers and analog channels.
4. Support for more than 255 analog channels has been documented to make life easy for IMU applications, Note that the C3D "analog" data can be any 16-bit data values, stored at potentially much higher data rates than the 3D point data. The interpretation of the data values is dependent on the applications reading and processing it, not the C3D format.

There have been multiple minor edits in the last month or two but I believe (I hope) that the documentation is now stable.