2 ms·

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-wri

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.

patrec 6y ago
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.

patrec 6y ago

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.