Image transparency problem on Nokia 5800 / S60 v5

[PapatorFR]

Hi,

I am developping a Java MIDlet application for my Nokia 5800 phone (S60 v5), trying to display real-time produced images on a GameCanvas graphic container. Unfortunately images transparency does not work, despite using specific Nokia UI API / DirectUtils / createImage method (mutable image creation) ; here is some code sample :

Image imageButtonPressed = DirectUtils.createImage(iWidth, iHeight,0x00AAAAAA);

I specified RGB color value with alpha-channel bits set to 0x00. Regarding to UI documentation it should work, but transparent pixels are displayed as white pixels.

Note : images are displayed using traditionnal Graphics / drawImage method.

Any ideas ?

Regards,

PapatorFR

[grahamhughes]

I just tried this on my 5800, and the image created has all white pixels, as if created by Image.createImage(width,height), exactly as you describe.

A similar bug exists on some early S60s, where the RGB values are used, but not the alpha (which makes the method pretty useless).

My recommendation would be to avoid this method (indeed, the entire Nokia API). It's not portable to other devices and, as you're discovering, implemented with varying reliability.

Unfortunately, there is no other way to achieve the same result.

Graham.

[tomuli]

Hi - I had a similar(ish) problem just a while back. On S40 I have this white alpha square, dynamically painted on background of a menu component to indicate the focus on a certain line. I create it by e.g.

DirectGraphics dg = DirectUtils.getDirectGraphics(g);
dg.setARGBColor(0x66FFFFFF);
g.fillRect(x, y, width, height);

so, this works fine on S40 - but S60 (the ones I've tested) just outputs 100%, no alpha at all. Then I tried the fillPolygon method under DirectGraphics, and that worked on S40, S60 3rd fp1 and 5, at least. Of course, as Graham said, the portability will be an issue - and I wouldn't be surprised if this method is implemented randomly on Nokians too...

[grahamhughes]

You say that fillRect() doesn't honour the alpha from setARGBColor(), but that fillPolygon() does? So, setARGBColor() works correctly, but fillRect() is broken? Am I understanding correctly?

Incidentally, an alternative way to paint an alpha rectangle (at least on some devices) is to include a PNG with a small square of the appropriate colour (with alpha at the level you want), set a clip region of the area you want to cover and paint the image as a repeated tile over that area. MIDP does not require support for alpha blending, but you should be able to determine if it is supported at runtime (on MIDP2 devices) by using Display.numAlphaLevels(). You'd be looking for a value greater than 2.

Cheers,
Graham.

[tomuli]

Yup, fillRect on S60 doesn't seem to care for the alpha value set in setARGBColor(). On fillPolygon() one of the parameters is the ARGB value, so I guess it is implemented differently. So, no need to use setARGBColor() with fillPolygon().

[grahamhughes]

Ah, of course. Sorry, I forgot that fillPolygon() specifies the colour as an extra parameter.

Cheers,
Graham.

[Utumno]

Hmm.. so no way to create a transparent mutable image, even if I only care about S60 5th edition? And only about full transparency?

Pretty incredible...

[grahamhughes]

No.

There are potential workarounds, depending on your situation. One is to draw on an opaque image, using some "magic colour" (a colour you promise not to use for anything else), which you can later replace with transparent.

private static final int MAGIC_COLOR = 0xff00ff;

// we could use the Nokia API, but let's keep it portable
Image buffer = Image.createImage(width, heigth);
Graphics g = buffer.getGraphics();
g.setColor(MAGIC_COLOR);
g.fillRect(0, 0, width, height);

// now... draw whatever you want

// next, transparantize!
int[] pixels = new int[width * height];
buffer.getRGB(pixels, 0, width, 0, 0, width, height);
for (int i = 0; i < pixels.length; i++) {
    if (pixels[i] == (0xff000000 | MAGIC_COLOR)) {
        pixels[i] = 0x00000000;
    }
}

buffer = Image.createRGBImage(pixels, width, height, true);

Bear in mind that the bit-depth of the image when you're drawing on it might not be 32 bit. When converting between Image, int[] and back, some pixel values might change slightly. Keep your "magic colour" to 0xff or 0x00 for each channel, to avoid it getting corrupted. Don't use colours when drawing that are even close to it. For example, 0xfe01fe might get adjusted to 0xff00ff when drawing to an image, if that's the closest colour value the image's colour model can represent.

Another option might be to create a transparent PNG, and use DirectUtils to create a mutable image from it (assuming that method works!).

Graham.

[Utumno]

Thanks...

Well, I know exactly which pixels I want to make transparent, so I guess I don't need any magic colors.

This is pretty much what I would like to do:

g= image.getGraphics();
g.setColor(TRANSPARENT);
g.fillRect(x,y,length,height);

except that, of course, for some convoluted reason setColor does not let you set the color to transparent and overwrite part of the image with that.

So to emulate the above, I understand I'll have to

1) getRGB
2) loop thru the pixels and replace those from (x,y,x+length,y+height) with 0x00000000
3) createRGBImage

Step no 3 will double the memory usage, which starts to be an issue, since the image we're taking about is the (5*scrWidth x 5* scrHeight ) 'bigImage' we're taking about in another thread...

[grahamhughes]

Yup, that's a problem. My advice would be: construct that image on the fly, direct to the screem, rather than rendering it all in advance. If you need "transparent", then just don't draw anything. But we can talk about that in the other thread.