Hacker News Reader

Comment by formerly_proven | Hacker News Reader

This is very nice.

If I had to nitpick something, I'd say choosing all-big-endian is kinda odd in 2021 but it's probably not a biggy even for something like this.

View on HN

Well, it's easier to read in a hex editor and seemed like the right thing to do for a "wire format".

The only places where it matters is the header's width/height and order of RGB(A) data. Storing RGBA as ABGR is not a great choice, imho. If you want to be endian independent, you have to read one byte at a time anyway (or swap).

why are channels interleaved at all if speed of decompression was the goal?

Because almost everywhere you would use data will expect it as interleaved. Separating the channels would require a second pass to re-interleave the data.

Storing rgba as abgr is a terrible choice, but are you sure they're actually doing that?

Sorry, I see how my previous comment was misleading. To clarify: No, QOI is not doing that. QOI stores RGBA as R,G,B,A because it is big endian.

Little endian would imply that RGBA is stored as A,B,G,R. Which was my argument against using LE for a file format.

I don't believe it would imply that, because those are independent elements. RGBA would still be stored as R, G, B, A unless you're considering each pixel as a single 32-bit integer. A C structure for the colors would even live in memory in the order you expect. Just like a string is still stored byte-by-byte even in little-endian contexts.

LE vs BE would only affect multi-byte integers and floats, not arrays or structures of single-byte elements.

ARGB would be nice if you want to integrate with Cairo.

Honestly no one should worry about endianess in 2021.

https://justine.lol/endian.html

Yup, as soon as you see anything that checks platform endianess, uses memcpy, or assumes memory layout, run.

Support for 16/32b and fp-formats would've been nice -- the compressor is actually orthogonal to the bit width of the channels. Custom fp-compression usually just unvolves moving the sign bit into the LSB, and delta encoding the mantissa separately from the exponent -- although the latter isn't as important.

This was my initial thought, but given how the format is designed, you would pretty much have to make a whole new set of tags for 16 or 32 bit images.

Yeah... seems like a small family would be in the right vein. I'm immediately drawn to a block format, but that'd probably double the complexity.

The bytes in the compressed data aren't going to be aligned to 2-, 4- or 8-byte offsets, so the overhead is going to be nonexistent or negligible.

Reply on news.ycombinator.com