Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Getting pixel data from a png Image

 
Punit Raizada
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Has anyone worked with the byte data returned my the getSnapshot() method of the VideoControl. I believe the default is png( i have tested this on Nokia 3650 and 6600 and on Siemens SX1).
In all the devices that support Nokia UI library i can get the pixel values from the byte data by using the com.nokia.mid.ui library, specifically the DirectGraphics.getPixels() method.
In MIDP 2.0 devices i can do this using the Image.getRGB method.
But what about MIDP 1.0.3 devices that do not have the Nokia library ? i believe that the byte data returned by the camera is of raw png format. I have never done this before and so far my search on the web has not been fruitful.
Can anyone point me to information abt the raw png Image (number of bytes of header ... etc) so that i can write my own code to extract the information or better yet point me to the code that does this.
 
Paul Kelcey
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic