MIRA voxel file format specification
This format is used by the
etdips software package. The source tree of this package
has code for reading and writing MIRA files (in tdips/Basic/MiraFormat.cpp).
It is also used by the "Multiresolution Isosurface Extraction with Adaptive Skeleton Climbing"
method described by Tim Poston, Tien-Tsin Wong, and Pheng-Ann Heng (Computer Graphics Forum,
17(3), September 1998, pages 137-148), and implemented in their package
ASC.
The header
The contents of the binary header can be defined in a struct:
typedef struct {
char fileid[5]; // must be VOXEL
byte control_z; // must be 26 (0x1a)
unsigned short version; // must be 1 (?)
unsigned short xres;
unsigned short yres;
unsigned short zres;
unsigned short flag; // 0x4 if RGB data, 0x8 if RGBA data, 0 = byte data
unsigned int map_offset; // must be 256
unsigned int voxel_offset;// equal to 256 + (xres + yres + zres) * sizeof(double)
byte unused[104];
char text[128]; // information text
} fileheader;
byte order
In the etdips source it reads that "no matter what the byte order is
we write it as big-endian" (in tdips/Basic/MiraFormat.cpp).
Unfortunately it is assumed in the source that "Unix is big-endian", so no
byte flipping takes place in the program under Unix (it only happens
when _WINDOWS is defined).
For this reason one may come across MIRA files both in little- and in big-endian
order.
The map
The map appears right after the header (i.e. at byte offset 256), and
contains the floating point values that the discrete steps in x, y, and z map to
(our reader software ignores these values).
The voxel data
After the map comes the voxel data, which depending on the flag setting in
the header (see above), has 1, 3 or 4 bytes per voxel. Our programs only support
1 byte per voxel. Continuous values are scaled to fit in the range [0, 255].
Click here to go back to the binvox
page.
Patrick Min
Last modified: Fri Jun 16 14:38:52 EDT 2006