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