I wrote this in a funny sort of mood when playing around with the
limitations of MIDP 1.0. Although I didn't actually have any use for
this myself, it has attracted more interest than anything else on my
site, so I happily decided to address it as a separate topic here ;-)
A minimal PNG stream
consists of a signature followed by a header chunk, a data chunk
and a trailer chunk. Each chunk is verified by a CRC checksum.
The data chunk contains a
representing the actual pixel data. In the spirit of writing a
minimal encoder, I used the most simple ZLIB block format
containing only uncompressed deflate blocks.
charge for any purpose you desire, as long as you do not claim credit
for the original sources and agree not to hold me responsible for any
damage arising out of its use. If you have a suitable location in GUI
or documentation for giving credit, I'd appreciate a mention of
PNG encoder (C) 2006-2009 by Christian Fröschlin, www.chrfr.de
but that's not mandatory. Of course, if you use my PNG encoder
in your application, I'd also be happy to hear about it.
Limitations: The image data remains uncompressed,
so the encoder may not be suitable for large images.
Extensions: Cody Konior has successfully combined
my PNG encoder with
for his Biorhythm application at
so you might wish to check out his encoder class if you are
looking for something with compression.
Related: Helmut Dersch has written a pure Java
Back to MIDP page
Fixed Adler checksum calculation and byte order
for storing length of zlib deflate block. Thanks
to Miloslav Růžička for noting this.
Added support for images > 64K by splitting the data into
multiple uncompressed deflate blocks. In the process, split
PNG and ZLIB functionality into separate classes.