Win a copy of Rust Web Development this week in the Other Languages forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Getting pixel data from a png Image

 
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic