Our bloat problem

Our bloat problem

Also don't forget the small ones, libpng is over 200kb on my system, just to interpret some metadata grouped into fourcc chunks. This exclusive decompression,

That's a rather simplistic view. libpng supports 19 pixel formats, depth-scaling, a moderately complex 2D interlacing scheme, alpha compositing, CRC verification, and various other transformations and ancillary bits. It also includes row-filtering, which is a fundamental component of the compression codec. I won't defend everything that's gone into libpng, but it's highly misleading to refer to all of it as bloat. If libpng (or a higher-level library built on top of it) didn't include it, all of your PNG-supporting applications would have to.

that is in libz (better, 80kb, but I remeber Pkzip being 30kb on my MS-Dos system).

Your memory is slightly faulty there. PKZIP 2.04g was 42166 bytes, and if all you care about is compressing your files, I can do far better with my 3712-byte trunc utility--and at 100% compression, too! But if you'd actually like to decompress them again someday, you'd better add PKUNZIP 2.04g, which rang in at 29378 bytes. IOW, the PKWARE codec was 71544 bytes (plus a number of other standalone utilities), while my copy of libz.so.1.2.3 is 71004 bytes--and 1.2.2 was 66908 bytes. Keep in mind also that significant parts of PKZIP and PKUNZIP were written in assembler, which, though capable of producing much smaller binaries, is generally not considered by most of us to be the most productive or maintainable of programming languages. (And, btw, libpng includes additional MMX assembler code for decoding row filters and for expanding interlace passes.)

I'm sure the Commodore Amiga was able to read iff files (on which png is based) in less code.

PNG was not based on IFF. The gross structure may have been suggested by someone familiar with IFF, but IFF itself was considered and rejected as a basis for PNG.

Greg