3 ms·

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

by patrec 6y ago

w0utert 6y ago
PPM P6 probably wasn't "handmade" enough I guess :D
harporoeder 6y ago
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.

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

by patrec 6y ago

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

w0utert 6y ago

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

harporoeder 6y ago

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.