Public Member Functions | |
| LookupTableV0Access (bool mustflip, bool isalpha, std::int64_t num_bricks=0) | |
| virtual podbytes_t | podbytes () const override |
| virtual void | read (const std::shared_ptr< FileADT > &file, std::int64_t offset, std::int64_t size) override |
| virtual void | byteswap () override |
| virtual void | dump (std::ostream &out, const std::string &prefix="") |
| virtual std::uint64_t | lookupLinearIndex (std::int64_t index) const override |
| virtual std::vector< std::uint64_t > & | lup () override |
| virtual std::vector< std::uint64_t > & | lupend () override |
| virtual const std::vector< std::uint64_t > & | lup () const override |
| virtual const std::vector< std::uint64_t > & | lupend () const override |
Additional Inherited Members | |
 Public Types inherited from InternalZGY::IHeaderAccess | |
| typedef std::vector< std::uint8_t > | podbytes_t |
Detailed Description
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.
The documentation for this class was generated from the following file:
- impl/meta.cpp
