Image.getRGB() issue for Nokia E50/E65

[amri_cse]

Hello...

I am working image scaling for the image using j2me code. I am calling Image.getRGB() method to get the ARGB data and then applying my scaling algorithm. I am facing issue only with E50/E65 device while calling Image.getRGB() method for transparent image. I am creating a full transparent image (alpha = 0x00) and then calling Image.getRGB() method but always alpha value returned is 255 in the ARGB data.

In this case I am not able to scale the image because alpha value is returned as 255 and after reconstructing the image (Image.createRGBImage()) the image losts its transparency. I know the problem is with Image.getRGB() method for E50/E65 device.

So is there any other way to do the scaling for transparent image? Please help me on this.

Thanks,
Amritendu

[grahamhughes]

Yup, I've seen this issue on other S60s (the 6680, I think). getRGB() returns pixels that are all opaque. The work-around my colleague devised was to ensure that all transparent pixels in the source image had a specific RGB value that did not appear in any opaque pixel (such as 0xff00ff). Then you can process the result from getRGB() and add the alpha back in. Unfortunately, this only helps you if you control the source image, and if you want only basic transparency (no 50% alpha, for example).

Graham.

[amri_cse]

Hi Graham,

Thank you very much for your reply.

Yes limitation is that we need to set a specific color value to that transparent image and also this work-around will not support for partial transparent images.

Thanks,
Amritendu

[grahamhughes]

What is the source of your images?

How desperate are you for a solution?

[amri_cse]

The source of the image will come from res: directory or from the network. Here we can't force to set to a specific color value for the transparent also partial transparent image need to be supported for image scaling. It's best to have a common solution otherwise we have to make a known issue for E50/E65 or similar devices for our product.

I can spend time on this if there any alternative way to do a generic solution that will be supported for all the devices which doesn't supports alpha component in Image.getRGB() method like for E50/E65.

[grahamhughes]

Is the source a PNG file?

[amri_cse]

Yes the source image will be always PNG image.

I and one of my colleague were discussing on a alternative solution and not to use Image.getRGB() method.

Using InputStream:
1. From network
InputStream is = Connector.openInputStream("http:\\server\myimage.png");
2. From res: directory
InputStream is = getClass().getResourceAsStream("./myimage.png");

From this InputStream we can create a DataInputStream and can read image content in byte[] array.

Now is there any way to convert byte[] arrey data to ARGB int[] array data which we get from Image.getRGB()?
Or if you have any other idea, please let me know.

[grahamhughes]

That's what I was going to suggest!

To do this, you'll either have to implement (or find) a ZLIB decompressor, or use PNGs that are already decompressed. You should be able to use something like PNGOUT to produce an uncompressed PNG. These will be huge, but they won't increase the JAR size much, since JARs are compressed with the same algorithm as PNGs.

How much control do you have over the images that come from the server? Can you control the precise format?

Graham.

[amri_cse]

Using ZLIB decompressor is a pain, we don't want to include it on client side because of performance. Currently we are using uncompressed image files only and even if there is a chance of compressed image in that case we can programiticaly change it to uncompressed mode while copying to res: directory or sending data from server.

In that case yes we have control for uncompressed data over the server and jar resource. I didn't get the meaning of "precise format", like as I told previously we can't control the RGB value for full opaque images, if it means uncompressed format than yes we have that control.

[grahamhughes]

Processing the PNG will be simpler if you guarantee that it is, for example, always 8 bits per pixel, or always 32 bits per pixel. Using 8bpp would make the uncompressed images smaller, and would make the process of converting the PNG data to an int[] faster, but would restrict you to 256 colours.

You can find the PNG format details here.

[CharlieHarks]

I'm also using a Nokia E65. So to get this to work you need to decompress the png image? How do I do that. Do I need to download some software?

Some people do recommend the fat burning furnace but not me.

[grahamhughes]

Where are your PNGs coming from? Are they in the JAR? You can create PNG files without compression... PNGOUT should be able to do this, use the "/s4" option (no compression) I think. You'll also want to specify either "/c3 /d8" (8 bit palette) or "/c6" (32 bit ARGB) to ensure you get a convenient format. For mobile, always use the "/mincodes2" option as well. If the PNG file is in the JAR, it is still compressed (JAR compression and PNG compression use the same algorithm), so while the PNG files will be much, much larger, the JAR file won't be (it's likely to be a little larger).

If you're not confident of decoding and manipulating PNG data in your own code, this solution might not be for you. You only need to consider this route if you need to process images with alpha values other than 0% and 100%.

Graham.