Problem creating PNG from Byte Array in J2ME

[Tommie Nygren]

For different reasons I am reading an array of bytes from a file in my
..jar-file and from this I want to create a PNG image using
Image.createIma ge(myArray, 0 , myArray.length) .

I had a prototype that did this and it worked fine. It was working on
a file with a series of PNG-images just thrown together, one after
another, the MIDlet read the bytes of each image in turn into an array
of bytes that was then used to create the image.

But I hade to process the images some more, reducing colors and create
palette (PLTE chunk) manually. So now the file looks something like
this:
IHDR-chunk
PLTE-chunk
IEND-chunk
and then any number of
IDAT-chunks
the IDAT chunks are PNG IDAT chunks as in the PNG specification. What
I do (to save space obviously) is I read the different chunks into
separate arrays and the put them together to create an image, JUST as
in the first prototype.

I have also written a small tester for all of this that reads the
abovementioned file in the EXACT same way the MIDlet does and puts the
bytes together in the EXACT same way as the MIDlet does and then just
writes them to a file. This file then... it is a valid PNG-image. I've
even run pngcheck on it and it's just fiine!

The error I get when doing all of this (Image.createIm age(myArray, 0 ,
myArray.length) ) is:

java.io.EOFExce ption

at java.io.DataInp utStream.readFu lly(DataInputSt ream.java:268)

at com.sun.kvem.pn g.PNGImageReade r.decodePass(Un known Source)

at com.sun.kvem.pn g.PNGImageReade r.decodeImage(U nknown Source)

at com.sun.kvem.pn g.PNGImageReade r.readImage(Unk nown Source)

at com.sun.kvem.pn g.PNGImageReade r.read(Unknown Source)

at com.sun.kvem.mi dp.GraphicsBrid ge.loadImage(Un known Source)

at com.sun.kvem.mi dp.GraphicsBrid ge.createImageF romData(Unknown
Source)

at sun.reflect.Nat iveMethodAccess orImpl.invoke0( Native Method)

at sun.reflect.Nat iveMethodAccess orImpl.invoke(N ativeMethodAcce ssorImpl.java:3 9)

at sun.reflect.Del egatingMethodAc cessorImpl.invo ke(DelegatingMe thodAccessorImp l.java:25)

at java.lang.refle ct.Method.invok e(Method.java:3 24)

at com.sun.kvem.Li me$Connection.c allMethod(Unkno wn Source)

at com.sun.kvem.Li me$Connection.p rocessCommand(U nknown Source)

at com.sun.kvem.Li me$Connection.r un(Unknown Source)

at java.lang.Threa d.run(Thread.ja va:534)

Might this be a problem with "Adler checksum"? I knew about the CRC
checksums and I generate these from the data and they are working fine
(otherwise the image wouldn't work anywhere else). The Alder checksums
are only related to the IDAT chunks and the deflate algorithm and I
thought these were written in the zlib stream, not outside of the
stream. This checksum is NOT specified in the PNG specification in the
Chunk Layout for instance, only mentioned in brief with regards to the
zlib stream. No algorithm is presented why this leads me to believe
(considering the images actually work everywhere else but in my
program...) that it is of no consequence to my problem.

I have also written a small tester, as mentioned above, that generates
a PNG-file which works. What I did today was adding code in my MIDlet
that loads a PNG-image from a file and tested it using two images, one
generated by some other program and one generated by my test-app.

The one I have generated gives me the exact same error message. This
leads me to believe that something after all is wrong with these
pictures, something that pngcheck fails to register and that NO OTHER
APP in the entire free world cares about...

//Tommie

[Tommie Nygren]

For everyones information I solved this problem just a couple of hours
later. The problem was, of course, that the image was corrupted in
some way. What happened was that I in my application that creates the
IHDR chunk stated that the image hade 96 lines when in fact it only
had 71. That pngcheck didn't react to this is seriously strange. What
happened, I realize now, is that all other applications just read the
image and displayed it in 96x96 and somehow just stretching the image
data to 96 lines. Image.createIma ge is not as forgiving though...

I discovered this by the filter byte information in pngcheck's output.
It gives you the filter type for each scanline (0-5 or whatever) and
in my case it just output 71 (the number of actual lines) of 96. All
other images seemd to have filters for each row (in fact they have to
according to the spec) specified...

Anyways, thanks for your time, hope this gives any pointers to you
people out there.

//Tommie

[pradeepunair]

hi friends
i am a newbie in j2me. i was trying to retrieve multiple images on the client side from a servlet. the servlet fetches the images, converts them into bytes and encodes them using base64.
on the client side it decodes and then again converts it back to byte array. the problem is that it shows an illegal argument exception upon converting it back to image by using the createImage() function.
could you please help me with this problem. :) :(