Farbfeld lossless image format: easy to parse, pipe, compress | Hacker News Reader

Farbfeld lossless image format: easy to parse, pipe, compress

tools.suckless.org

35 pointsstargrave13 comments

Sweet no identification of color space, gamma, and forced storage of the alpha channel. What a great format! /s

PNG is pretty stupid easy to parse and supports inline compression and multiple bit depths. If you want some uncompressed format that's easy to pipe and parse just use the NetPBM family.

Images are not just 2D arrays of pixels. There's extra data needed to tell the viewing system some of the image's provenance so it does so correctly.

Writing a naive PNG parser is easy, but handling all the corner cases is harder than it should be, e.g. text chunk fields can be variable- and even zero-length:

1. https://github.com/randy408/libspng/blob/3439bf5c173421b1af4...

2. https://www.w3.org/TR/2003/REC-PNG-20031110/#11iTXt

Color space and gamma are clearly identified as sRGB.

This is exactly what you need for the intermediate stages of a video game asset pipeline where you have a prepared set of images ready to be re-encoded to compressed and packed textures: you don't want the overhead of decoding PNG at that stage, neither do you want a text parse like PPM. Bytes that can be used directly are good.

It's a hugely uninteresting format in most respects.

The FAQ claims the compression achieved is good, but without a single concrete example -- lets see some comparisons to PNG?

The compression is as good as the compression tool you use on farbfeld file. From description this looks like BMP with less features. Since it is part of suckless project I am quite sure that there indeed is nothing more to it.

or just use PPM which is already supported everywhere

This seems literally some completely superfluous reinvention of PPM P6. What's wrong with the suckless guys?

While the justification may not be satisfactory they do call this out in the FAQ:

    NetPBM's big vice is that it has originally been developed to be hand-written and passed around as plain text. A binary format exists, but still handling optional comments in the header, base 10 ASCII width and height values, arbitrary whitespace inside the data and out-of-band image size and color depth is too painful for the sane user.

Thanks for alerting me to the existence of the faq, which I had missed (in fact even after you mentioned it it took me a bit to find it on the page)!

It makes more sense now.

So bascically the idea is P6 is too complicated. And you don't need (color-space, bit=depth etc.) metadata -- just add a side-car XMP file, and your non-existing resource fork based file system will take care of the rest; at least once you've got a good understanding of XMP (specs 1,2 and 3) and a full featured parser for it. You also won't need anything other than 16-bit depth, because 16 bits is the most you'll ever need (I wonder if the author heard of floating point image data) and if you use just 8 (or 1/3) bits per channel, bzip2 compression will take care of it. So if you have a high resolution monochrome image, you don't need to deal with some complicated data format like netpbm P4 where the first two bytes ("P4") will tell you to expect a monochrome bitmap, you can just first run a bzip2 decompression and then inspect millions of 64 bit values to see if they all are 0x0000 and 0xffff or something. Simple and efficient!

I mean I see the appeal of some of the thinking behind this, but without a lot of wishful thinking/false accounting I find it a bit hard to see how this would work out as an actual simplification in any practical scenario. Still, as a thought-experiment it's more interesting than I had given it credit for.

PPM P6 probably wasn't "handmade" enough I guess :D

Why big-endian?

1. Optimizing for a big-endian CPU?

2. Optimizing for hex dump programs that don't have a setting for endianness?

3. Ideological purity?

No color space support and sRGBA enforced. It's no accident then, that the domain is called suckless.org. Staircase wit.

Reply on news.ycombinator.com