|
Haio 0.2.X
Homebrew Asset IO/CDN
|
Namespaces | |
| namespace | Tga |
Classes | |
| struct | DefaultColor |
| struct | DefaultColor< Format::GIF > |
| struct | DefaultColor< Format::JPEG > |
| struct | DefaultColor< Format::PNG > |
| struct | DefaultColor< Format::PPM > |
| struct | DefaultColor< Format::ROM > |
| struct | DefaultColor< Format::TGA > |
| struct | DefaultColor< Format::ZCIS > |
Concepts | |
| concept | HasDefaultColor |
| concept | Detectable |
| concept | Decodable |
| concept | Encodable |
| concept | Movable |
| concept | Convertible |
the verbs. they live apart from the vocabulary above because the runtime facade in haio_registry.hpp offers Decode(const Blob&) and Detect(Bytes) with the very same parameter lists: without a namespace between them, Decode(blob) and Decode<Format::PNG>(blob) read alike and do different things.
| struct Haio::Codecs::DefaultColor |
the colour a format carries when nobody says otherwise. only formats with a real answer declare it: a ktx2 holds any of three, so Decode<Format::KTX2> alone is a compile error telling the caller to be specific.
Definition at line 143 of file haio_codec.hpp.
colour to colour, no file involved. the heavy ones live behind Move

| Result< Image< Color::PALETTE > > Haio::Codecs::Convert< Color::CHR_NES, Color::PALETTE > | ( | Image< Color::CHR_NES > | src | ) |
the indices arrive without colours. what to hang on them is a separate question, answered by whoever asked for the conversion, because a chr file does not carry a palette and never did: the console held it somewhere else entirely.
Definition at line 1 of file palette.cpp.

| Result< Image< Color::RGBA8888 > > Haio::Codecs::Convert< Color::PALETTE, Color::RGBA8888 > | ( | Image< Color::PALETTE > | src | ) |
indices become the colours they point at.
this one direction is always possible and never loses anything, which is why it needs no filter while the way back does.
Definition at line 1 of file rgba8888.cpp.

| Result< Image< Color::YUV420 > > Haio::Codecs::Convert< Color::RGBA8888, Color::YUV420 > | ( | Image< Color::RGBA8888 > | src | ) |
| Result< Image< Color::RGBA8888 > > Haio::Codecs::Convert< Color::YUV420, Color::RGBA8888 > | ( | Image< Color::YUV420 > | src | ) |
the shape every Convert specialisation has: check, allocate, hand the work to Move. it lives here so a new colour pair is one Move and one line instead of ten.
Definition at line 21 of file haio_convert.hpp.


| Result< Image< Color::YUV420 > > Haio::Codecs::Decode< Format::JPEG, Color::YUV420 > | ( | const Blob & | blob | ) |
straight to yuv planes, which is what the file already holds.
a jpeg is yuv all the way down, so a decoder that hands back rgb has both thrown away the chroma layout and spent the work doing it. asking for the planes means the picture arrives as it was stored, and whoever wants rgb converts once, visibly.
only 4:2:0 is read. it is what cameras and ad creatives produce, and reading 4:4:4 or 4:2:2 into a buffer sized for 4:2:0 would quietly truncate the chroma rather than fail, so those are refused instead.
Definition at line 14 of file decode.cpp.
| Result< Image< Color::CHR_NES > > Haio::Codecs::Decode< Format::ROM, Color::CHR_NES > | ( | const Blob & | blob | ) |
every pattern table in the cartridge, stacked one below another.
the header says where they start: sixteen bytes of it, then a trainer if there is one, then the program itself, and only then the pattern data. picking which bank to look at is left to the caller, because by then it is a crop.
Definition at line 14 of file decode.cpp.
deleted on purpose. a codec declares only the pairs it can do, and naming one it left out is ill-formed, which is what lets the concepts below answer for themselves instead of failing at link time. drop a codec from the build and its format stays in the enum, naming itself, with every capability gone.


| Result< Blob > Haio::Codecs::Encode< Format::ANSI, Color::RGB888 > | ( | Image< Color::RGB888 > | img | ) |
one terminal cell per pixel, coloured by its background.
the picture ends up half the height of the utf8 one for the same number of rows, and it works on anything that can colour a background, including terminals with no font to draw a half block with.
Definition at line 12 of file encode.cpp.
| Result< Blob > Haio::Codecs::Encode< Format::JPEG, Color::YUV420 > | ( | Image< Color::YUV420 > | img | ) |
from yuv planes, which is what a jpeg wants.
anything else converts first, and does so where the caller can see it: an encoder that quietly accepted rgb would hide a colour conversion inside what looks like a container change.
Definition at line 17 of file encode.cpp.
| Result< Blob > Haio::Codecs::Encode< Format::UTF8, Color::RGB888 > | ( | Image< Color::RGB888 > | img | ) |
two pixel rows per terminal row, using the upper half block.
the foreground paints the top pixel and the background the bottom one, which buys twice the vertical resolution of the ansi rendering for the same number of lines and makes the aspect ratio come out roughly square.
an odd number of rows leaves the last cell with nothing below it, and its background is left black rather than repeating the row above: a doubled last line reads as part of the picture, a dark one reads as the edge.
a terminal keeps the colour it was last told, so saying it again is bytes nobody reads. a picture in few colours repeats itself constantly, and this is exactly the picture somebody renders in a terminal.
the pair is tracked rather than each half, because a cell sets both at once.
Definition at line 12 of file encode.cpp.
the hot loop under Convert, and what a codec calls when it wants to write pixels straight into a buffer it already owns. dst is sized by the caller so the simd paths can rely on it, and size is here because block formats like etc1 cannot be transformed pixel by pixel.
it reports rather than assumes: the loop runs once per image, so one Result on the way out costs nothing next to the work inside it.

| Result< void > Haio::Codecs::Move< Color::CHR_NES, Color::PALETTE > | ( | Bytes | src, |
| std::span< uint8_t > | dst, | ||
| Size | size ) |
unpacks nes pattern data into one index per byte.
a tile is sixteen bytes: eight rows of the low bit, then eight rows of the high bit. so a pixel's two bits sit eight bytes apart, and the leftmost pixel is the most significant bit rather than the least.
nothing here needs a palette, which is why it fits Move at all: the indices are 0 to 3 whatever colours are eventually hung on them.
Definition at line 1 of file palette.cpp.
| Result< void > Haio::Codecs::Move< Color::RGBA8888, Color::YUV420 > | ( | Bytes | src, |
| std::span< uint8_t > | dst, | ||
| Size | size ) |
the way back: full range bt.601 again, and the chroma of a two by two block is the average of its four pixels rather than the top left one.
taking one pixel and calling it the block would be cheaper and is what a naive encoder does; it shows up as ragged colour on edges, because the sample that happened to be first decides for three others.
Definition at line 1 of file yuv420.cpp.
| Result< void > Haio::Codecs::Move< Color::YUV420, Color::RGBA8888 > | ( | Bytes | src, |
| std::span< uint8_t > | dst, | ||
| Size | size ) |
jfif colour, which is full range bt.601 and not the studio range video uses. a decoder written against the video coefficients produces a picture that is visibly washed out rather than obviously wrong, which is the sort of mistake that ships.
the two chroma planes are half size in both directions, so each of their samples covers a two by two block of luma.
Definition at line 1 of file rgba8888.cpp.