Forums Register Login

Getting pixel data from a png Image

+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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
They gave me pumpkin ice cream. It was not pumpkin pie ice cream. Wiping my tongue on this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 2142 times.
Similar Threads
Gray scale unformatted images
j2me: upload an image file captured by cell camera
Failed to load byte array of an png image into an midp application
Why did it have to be PNG
How can i get a pixel value of .png image in J2ME?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Apr 10, 2024 00:39:39.