What they don’t tell you about VTK XML binary formats

You might have been trying to implement the new-style VTK XML file formats. And you might have realized that what they tell you in the file format “specification” is just incomplete. Well, here are a few bits of information missing from there:

Binary Blob Header: In front of every binary blob, base64 or raw-binary, appended or not, there is an UInt32 length indicator. If you do not have this length indicator, you might get error messages like

Cannot read cell offsets from XXXX in piece 0 because the "offsets" array is not long enough.

Note that if you are encoding in base64, that length header must be encoded separately, so that the end result looks like XXXXXX==XXXX… (note the two equals signs indicating the early end of the length header block).

Compression Header: If you use compression, the following header applies instead:

struct {
  uint32 blocks; 
  uint32 blocksize; 
  uint32 last_blocksize; 
  uint32 compressed_blocksizes[];
};

Again, this header is encoded separately from the data. This was figured out by Thomas Svedberg. Thomas adds that the following works for him:

struct {
  uint32 blocks = 1
  uint32 blocksize = total data size
  uint32 last_blocksize = total data size
  uint32 compressed_blocksizes[] = compressed data size
};

Offset Field Meaning for base64: The “offset” field on DataArrays with format=”appended” is not a binary offset, it is the base64 character count from the underscore that starts the AppendedData section.

Vector Element Order: If you are encoding vectors (i.e. anything with NumberOfComponents=”3”), and suppose your vectors are X,Y,Z,…, then the encoded data stream has the ordering X[0], X[1], X[2], Y[0], Y[1], Y[2], Z[0]…