Both the Alpha lookup table and the Brick lookup table hold a 64-bit
file offset for each tile or brick in the file. Alpha tiles are bitmaps
used to flag dead traces, and only have (i,j) coordinates. Bricks
contain the actual samples and are indexed with (i, j, k).
The size of the lookup tables depend on the survey size. The first
entry in the lookup table is for the brick or tile (always just one)
holding the lowest resolution. This is immediately followed by one
or more entries for the bricks or tiles at level of detail N-1, and
so on until the entries for lod 0. Within one lod level the first
entry is for the lowest numbered i,j,[k]. For subsequent entries the
i numbers vary fastest and the k (or j in the alpha case) varies
slowest. Note that this is somewhat non intuitive as it is the
opposite of the ordering of samples within a tile.
In version 1 of the lookup tables the file offsets are stored in a
somewhat quirky manner. The high 32 bits and the low 32 bits are
both stored as little-endian integers, but the high part is stored
first. So it is part big-endian, part little-endian.
An offset of 0 means the corresponding brick or tile does not exist.
An offset of 1 means the brick or tile contains all zeros and does
not take any space on the file. An offset with the most significant
bit set also means the brick or tile has a constant value. In this
case the actual value is encoded in the least significant 8/16/32
bits (depending on valuetype) of the stored offset.
Offsets 0x8000000000000000 and 0x0000000000000001 are equivalent.
Actually, v2 and later uses the first form while v1 used the second.
For robustness both forms should be accepted regardless of version.