OutOfMemory when loading a huge JPEG in S40

[fletcher.jonnes]

We are trying to load a JPEG of about 300kb in a 3120Classic(S40) and in the load moment our device run out of memory(as described by the exception). In a device of S60(N73) we don't have this kind of problem, so we believe that problem is the limited heap size of the S40 devices. The apps is something like a file navigator, where the user select between a thumbs to see a image in his real size, but we couldn't load the image because of the exception.

We have tried some optimizations in the source, but without great success. So, our last idea is to load just a part of the JPEG. We have thought two ways to do this:

1. Load a part with the Image class. The problem here is that to do this, the image have to be loaded a lest once, which are not possible;

2. Head bytes of the image with a stream and "collect" just the bytes of a desired part of the image. Doing some research, we found some documentation(http://en.wikipedia.org/wiki/JPEG) about JPEG files, but we can't understand how to get just de bytes of image data.

Is this possible? Did you have done something like this, and can give us some tips? Our could point us to a java documentation about bytes and possibly JPEG encode.

Thanks for your time reading this.

[grahamhughes]

How big is the image (in pixels, not bytes)?

[Tiger79]

hehe, I've seen PNG images being bloated a tenfold from their "original" size, i.e I've been sending 30kb PNG images (the size of the screen so that would be 240x320) from a server after which when drawn onscreen they would take around 350kb memory !!!
So I dont wanna think what a 300kb image would do, but one thing is for sure : i definitely believe you when you say a series 40 with 2 megs of heap gives an outofmemory exception....

just try to cut down the image sizes and use png (8 bit if no transparancy is used) instead of jpeg...

[fletcher.jonnes]

@grahamhughes
The picture was taken with the device camera. One image, for example, has 336kB and is 1200px x 1600px. So, as our screen is 240px x 320px (in this case, and supossing that we could use the whole screen) we want to take just this portion of the image(starting at a (x,y) coordinates) and show it to the user.

@Tiger79
Yes, it's a problem! I've read somewhere(I can't remember where, sorry), that this problem is because the device can show just bitmap images. And to show a JPEG or a PNG it has to decompress the image and doing that, it use a lot of memory to store the bitmap. Please, someone correct me if I'm wrong.
At the beggining of this project the PNG was what we are working on, but the server app (which will receive the image) could not receive a PNG file, so we have to work with the JPEG. And some devices don't have the option to chance de image format to another than JPEG (or JPG).

What we have to do is take the bytes from a part of the image, and create a smaller one, but until now, we couldn't understand how reach this bytes.

We still trying to find a way to do that, and will report back if find something.
Thanks!

[grahamhughes]

1200x1600 is the important information.

When an image is loaded, it is decompressed to whatever format suits the device's hardware. This is so the image can be drawn quickly... it would be very slow to decompress the data every time the image is drawn.

Remember, when we talk about memory use, there is some device variation.

First: the size of an Image object...

There is some overhead for an Image object, between 50 and 100 bytes. This holds information like the width and height of the image. Then, there is the pixel data. On some devices, this is held in the Java heap as a byte[] (Series 40s do this); in others it's in a special "image-heap" (this is typical on Sony Ericsson devices). Series 60's store images outside the Java environment, as "native" objects.

The size of the pixel data is width x height x bytes-per-pixel. The number of bytes per pixel depends on device, and varies between 1 and 4.

1200x1600 = 1920000 pixels. Even at just two bytes per pixel, that's 3Mb of data. On some devices it could be 6Mb.

Second: the peak memory usage when creating the image. Obviously, you need enough free memory to create the Image object. You also need enough memory to load the file - typically, the file will be loaded into a byte[]. So, if your file is 336k, you need another 336k free to load it. There is also some workspace required to decompress the image. This depends on device and format (png, jpg, etc). This can be quite significant... on some Motorolas, decompressing a PNG needs about 32k of extra space.

I'm not an expert on the JPEG format, but I doubt you can cut the image up without decompressing it. You can load the bytes from the file, using Class.getResourceAsStream(). How you would process that, I have no idea.

Maybe you can chop the image on the server... you might look at the Java Advanced Imaging API. JAI provides a lot of support for manipulating images.

Sorry I can't offer a solution, but I hope you at least know the scale of the problem.

Cheers,
Graham.

[fletcher.jonnes]

Hmmm... we thought that the problem was something like that, and your informations just confirm that it is true. The server processor is a good idea to solve this, but we have some problems with data transmission, once that our connections is basically GPRS/EDGE, but we will try this solution as a workaround.

Thinking better, we could see that read just the data bytes would no be enough, because of the decompression we would have to cross these data with the tables of compressions and so on. It would be an Herculean task and would demand too much time, and at the end we could just notice that the kvm could not have enough resources to accomplish it.

We hope that this discussion help others with the same problem, 'cause we have found so much threads like this one but without a good explanation like this or even an answer.

Thanks so much for your time!