Hi,
I've worked with PNG images with MIDP 1. You need to have a look at some RFCs regarding PNG images as well as Deflate compression. I can't remember the RFC numbers but you'll find them on google. Look for PNG specification 1.0 and Deflate compression. There are later specifications for PNG but the MIDP 1.0 spec explicitly says PNG specification 1.0.
Basically I was working on a streaming video player. I was doing the opposite you need to do (i.e. pixel data -> PNG). I wrote an encoder and you need a decoder. You have a much harder task because PNGs can come in a variety of flavours (eg. direct colour model or indexed colour model). I only had to write from one. Unless you can tightly control the PNGs you're getting, you're going to need to be able to read from many different types.
In all cases the pixel data is in the IDAT chunk. The IDAT chunk is compressed however (though Deflate also supports a NO compression mode). This means you have to screw around with canonical huffman trees and it gets complicated quickly (at least for my simple brain).
If you can find some free source code for ZIP or GZIP compression, I think they will de-compress deflate. Alternately, you can look for some open source PNG decoders they *might* help. All the
Java code for PNG decoders I looked at used the natively implemented zipstream class. This doesn't exist in MIDP (only J2SE) so you're back to looking for open-source ZIP/GZIP/Deflate compression code. Personally, I'd look for some C code that did it and convert into a fat and dirty Java class. Otherwise there's no way you are going to get it to fit on any devices.
I think it's a reasonably tricky undertaking but it's not impossible. You might have some performance concerns too (though decoding means you don't have to check addler-32 or CRC checksums which is good).
PK