Re: [android-developers] Re: PNG loading that doesn't premultiply alpha?

For the benefit of anyone else finding themselves here.

The solution outlined here worked for me:

http://gamedev.stackexchange.com/questions/53638/android-loading-bitmaps-without-premultiplied-alpha-opengl-es-2-0

My actual implementation differs slightly from the description on gamedev because I was already multiplying the texture color by two different variable color vectors (one for the sprite and another global color).

Because of this I ended up passing separate alpha value to the shader(s) and forcing the alpha value on the variable colors to 1.0f.

In the end, my fragment shader looks like this:

varying float v_Alpha; // Independent alpha value to account for premultiplied alpha values in PNG files

...

gl_FragColor = texture2D(u_Texture, v_TexCoordinate) * u_Color * v_Color * v_Alpha;

u_Color is a uniform color, v_Color is variable (for the sprite) and v_Alpha is the single float value for alpha.

This means I can use:

GLES20.glBlendFunc(GLES20.GL_ONE, GLES20.GL_ONE_MINUS_SRC_ALPHA);

Which accounts for the premultiplied alpha values in the PNG.

The upshot is I can continue to use the BitmapFactory to load the textures.

I can't be sure, but I suspect the artifacts I was seeing were as result of NOT using pre-multiplied alpha textures.

Still not sure what the blur on the textures was caused by when using GL_CLAMP_TO_EDGE :/

Peace out.

On Monday, September 2, 2013 6:45:23 PM UTC-7, Jason wrote:

P.S.  It turns out the blur is from using GL_CLAMP_TO_EDGE.  Changing to GL_REPEAT removes the blur even though it doesn't really make sense to repeat the texture as I'm just rendering sprites as quads (triangle pairs).

On Monday, September 2, 2013 6:29:17 PM UTC-7, Jason wrote:

On Monday, September 2, 2013 6:23:43 PM UTC-7, Jason wrote:

I realize this is an old thread, but I'm having the same issue and the above solutions haven't worked for me.

Firstly the link to the PNGDecoder from libgdx is old and no longer exists (libgdx appear to have re-vamped the way they load images and tracking down where exactly the PNG decoding happens is a bit of a nightmare)

I tried directly calling GLES20.glTexImage2D using the pixels extracted from the Bitmap (as described above), but I still get gray artifacts on the edges of the texture.

For example:

The top image is the original PNG, the bottom is after rendering (taken from screenshot)

The bottom image has gray pixel artifacts around the edge.  It's also sort of blurry which I can't work out either.

I tried manually decoding the PNG using this:

http://wiki.l33tlabs.org/bin/view/TWL/Using+the+TWL+PNGDecoder

But got the same result.

I'm creating the texture with:

GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MIN_FILTER, GLES20.GL_LINEAR);

GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MAG_FILTER, GLES20.GL_LINEAR);

GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_WRAP_S, GLES20.GL_CLAMP_TO_EDGE);

GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_WRAP_T, GLES20.GL_CLAMP_TO_EDGE);

My fragment shader is pretty basic, just multiplies the texture color by a couple of other color values I pass in:

gl_FragColor = texture2D(u_Texture, v_TexCoordinate) * u_Color * v_Color;

Does anyone have a clue as to:

1) How I can render/create the texture without the artifacts

2) Why the texture is kind of blurry once it's rendered.

Thanks!

On Sunday, September 2, 2012 11:43:59 AM UTC-7, arberg wrote:

Hi,

I think it would make sense that either Bitmap could be without premultiplied alpha, or GLUtils.texImage2D method could take as parameter whether to load with or without premultiplied alpha. Since you say Bitmaps will never be without premultiplied alpa, I suggest the latter, plus as you suggest a convenience method on the Bitmap, which returns its content in an array without premultiplied alpha.

It makes sense to me to add the option to GLUtils.texImage2D since the very purpose of the GLUtils class is '... to help bridging OpenGL ES and Android APIs.' (javadoc class reference).

Cheers Alex

On Friday, 29 June 2012 21:18:59 UTC+2, Romain Guy (Google) wrote:

Another big issue similar to alpha-premultiply is that 32Bit ARGB Images are changed

to 16Bit after scaling (especially if all alpha values are 255), without some dirty tricks.

This is a big issue to, it's far away from the precission needed for good normal mapping.

There was a bug in the scaling code that I fixed. a 32 bits image will now always be scaled to another 32 bits image.

 

--
Romain Guy
Android framework engineer
roma...@android.com

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.