InternalZGY::LookupTable Class Reference

Static methods to assist working with lookup tables. More...

#include <lookuptable.h>

Classes
struct	LutInfo
	Decoded contents of the lookup table for one brick or tile. More...

Static Public Member Functions
static std::vector< std::uint64_t >	calcLookupSize (const std::vector< std::uint64_t > &lookup, std::int64_t eof, std::int64_t maxsize)
static LutInfo	getAlphaFilePosition (std::int64_t i, std::int64_t j, std::int64_t lod, const std::vector< std::array< std::int64_t, 3 >> &lodsizes, const std::vector< std::int64_t > &alphaoffsets, const std::vector< std::uint64_t > &alup, std::int64_t bytesperalpha)
	Get file offset for the specified alpha tile.
static LutInfo	getBrickFilePosition (std::int64_t i, std::int64_t j, std::int64_t k, std::int64_t lod, const std::vector< std::array< std::int64_t, 3 >> &lodsizes, const std::vector< std::int64_t > &brickoffsets, const std::vector< std::uint64_t > &blup, const std::vector< std::uint64_t > &bend, std::int64_t bytesperbrick)
	Get file offset or constant-value for the specified brick.
static void	setBrickFilePosition (std::int64_t i, std::int64_t j, std::int64_t k, std::int64_t lod, const LutInfo &info, const std::vector< std::array< std::int64_t, 3 >> &lodsizes, const std::vector< std::int64_t > &brickoffsets, std::vector< std::uint64_t > *blup, std::vector< std::uint64_t > *bend)
	Set file offset or constant-value for the specified brick.

Detailed Description

Static methods to assist working with lookup tables.

I am uncertain whether I should extend this class. Some alternatives are:

• (1) [current choice] the LookupTable instance has no data members and only static methods. All context needs to be passed in. Which is tedious but makes it easier to see what the methods are actually doing.

• (2) The LookupTable instance is meant to be short lived. It has references to the context it needs but no good memory management or ways to handle stale data.

• (3) The LookupTable instance owns the actual lookup tables making this class more visible than just a helper for collecting lookup table related code. ZgyInternalMeta will hold a reference to a LookupTable instead of the current pointer to an ILookupTableAccess

• (4) As (3) but use separate instances for alpha and brick. Make some changes to have the methods more generic. Implement the boilerplate code from ILookupTableAccess. The code then becomes a drop in replacement for LookupTableV0Access.

Member Function Documentation

calcLookupSize()

std::vector< std::uint64_t > InternalZGY::LookupTable::calcLookupSize ( const std::vector< std::uint64_t > &  lookup, std::int64_t  eof, std::int64_t  maxsize  )

static

Given an index => start_offset lookup table, produce an index => end_offset table by assuming there are no holes in the allocated data.

The function understands constant-value and compressed blocks.

If eof and maxsize are known, the code can also make the following checks:

Blocks that have a start offset > eof are unreadable and should be ignored. Set them to start and end at eof. The same applies to offsets of unknown type i.e. the most significant bit is 1 but the most significant byte is neither 0x80 (constant) nor 0xC0 (compressed). Blocks ending past eof should be assumed to end at eof.

Blocks that appear to be larger than an uncompressed block are probably too large. This may be caused by holes in the allocated data. Assume the block is the same size as an uncompressed block. If a compressed block takes up more room than an uncompressed one then the writer should simply refrain from compressing it. But for extra robustness the code that makes use of this information should be prepared to retry the access of the block really turned out to be larger.

This method might be called unconditionally on file open, or called only if at least one compressed brick was found, or it might be deferred until the first time we read a compressed brick.

TODO-Low: If alpha tiles are present then both brick and alpha offsets ought to be considered in the same pass. The way it will work now is that for bricks, a few bricks will appear too large because they are followed by some alpha tiles. This is harmless. For aplha tiles the end offsets will be hopelessly wrong. We will need to just assume 4 KB for those.

---

The documentation for this class was generated from the following files:

• impl/lookuptable.h
• impl/lookuptable.cpp