Haio::Codecs::Tga Namespace Reference

Classes
struct	Header

Functions
bool	hasFooter (Bytes data)
Result< Header >	readHeader (Bytes data)
std::optional< Color >	colorOf (const Header &header)

Variables
constexpr size_t	headerBytes = 18
constexpr size_t	maxPixels = size_t{1} << 28
constexpr std::string_view	footerSignature = "TRUEVISION-XFILE."
constexpr size_t	footerBytes = 26

Detailed Description

the eighteen bytes every tga starts with, read once for the three files that need them. it is a header beside the sources rather than a third .cpp because nothing outside this directory has any use for a targa header, and the build scans .cpp files for capabilities: a helper that lived in one of them would be shared by accident or copied on purpose.

Function Documentation

colorOf()

std::optional< Color > Haio::Codecs::Tga::colorOf ( const Header & header )

inline

which of haio's colours these bytes already are.

a tga stores what haio calls bgr888, bgra8888 and the two fives-and-ones outright, so the answer is a layout rather than a conversion: that is the whole reason those colours exist, and why decoding one is a copy and not a loop.

Definition at line 176 of file header.hpp.

Here is the call graph for this function:

hasFooter()

bool Haio::Codecs::Tga::hasFooter ( Bytes data )

inline

the signature sits eight bytes into the footer, after the two offsets

Definition at line 73 of file header.hpp.

Here is the call graph for this function:

readHeader()

Result< Header > Haio::Codecs::Tga::readHeader ( Bytes data )

inline

the header, made to prove itself.

every other container haio reads begins with bytes that mean nothing else. a tga begins with its own dimensions, so there is nothing to compare against and the only question that can be asked is whether the eighteen bytes are consistent: a type it names, a depth that type can have, a colour map exactly when one is called for, and a file long enough to hold what all of that promises. anything less strict would make tga the answer for every unrecognised file.

a compressed picture is as long as it turns out to be, so it cannot be measured the way a plain one can. what can be said is the most it could possibly be: a packet is a count byte and at least one unit, and it covers at most 128 pixels. a file that does not reach even that is either truncated or claiming a size it means to be expanded into.

Definition at line 92 of file header.hpp.

Here is the call graph for this function:

Variable Documentation

footerBytes

size_t Haio::Codecs::Tga::footerBytes = 26

inlineconstexpr

Definition at line 35 of file header.hpp.

footerSignature

std::string_view Haio::Codecs::Tga::footerSignature = "TRUEVISION-XFILE."

inlineconstexpr

what a tga 2.0 writer leaves at the end of the file: two offsets nobody here uses and a signature that is the only thing about the format anybody can recognise outright. haio writes one so its own files are named by that rather than by the guesswork below.

Definition at line 34 of file header.hpp.

headerBytes

size_t Haio::Codecs::Tga::headerBytes = 18

inlineconstexpr

Definition at line 17 of file header.hpp.

maxPixels

size_t Haio::Codecs::Tga::maxPixels = size_t{1} << 28

inlineconstexpr

an image this large would not fit anyway, and a header claims it in four bytes.

the same number the netpbm decoder uses, for the same reason: the dimensions are read before there is any picture to measure them against, and a run length payload is not bounded by the size of the file the way a plain one is.

Definition at line 26 of file header.hpp.