5

I'm new to Renderscript, and am striking issues with my first script. As far as I can see (from debugging statements I've inserted) my code works fine, but the computed values are getting mangled when they are being copied back to the Bitmap by the Allocation.copyTo(Bitmap) method.

I was getting weird colours out, so eventually stripped down my script to this sample which shows the problem:

void root(const uchar4 *v_in, uchar4 *v_out, const void *usrData, uint32_t x, uint32_t y)
{
   *v_out = rsPackColorTo8888(1.f, 0.f, 0.f, 1.f);

   if (x==0 && y==0) {
      rsDebug("v_out ", v_out->x, v_out->y, v_out->z, v_out->w);
   }
}

Here we are just writing out an opaque red pixel. The debug line seems to print the right value (255 0 0 255) and indeed I get a red pixel in the bitmap.

However if I change the alpha on the red pixel slightly:

*v_out = rsPackColorTo8888(1.f, 0.f, 0.f, 0.998f);

The debug prints (255 0 0 254) which still seems correct, but the final pixel value ends up being (0 0 0 254) ie. black.

Obviously I suspected it was a premulltiplied alpha issue, but my understanding is that the Allocation routines to copy from and to Bitmaps is supposed to handle that for you. At least that's what Chet Haase suggests in this blog post: https://plus.google.com/u/0/+ChetHaase/posts/ef6Deey6xKA.

Also none of the example compute scripts out there seem to mention any issues with pre-multiplied alpha. My script was based on the HelloComputer example from the SDK.

If I am making a mistake, I would love an RS guru to point it out for me.

It's a shame that after 2+ years the documentation for Renderscript is still so poor.

PS. The Bitmaps I'm using are ARGB_888 and I am building and targetting on SDK18 (Android 4.3)

Paul LeBeau
  • 97,474
  • 9
  • 154
  • 181
  • how about if you just modify the rgb values not the alpha? – Onur A. Aug 06 '13 at 12:56
  • It is changing the alpha that is the issue. I probably didn't make that clear. As long as alpha converts to 255 everything is fine. If it is anything else, the pixels get mangled. – Paul LeBeau Aug 06 '13 at 17:00
  • Since other examples apparently work fine for other people, I am wondering if it is an Android 4.3 issue or maybe ADT 20.0.5. – Paul LeBeau Aug 06 '13 at 17:17
  • how are you creating the Allocation? createFromBitmap? what are the usage flags? – Tim Murray Aug 06 '13 at 17:49
  • Allocation.createFromBitmap(mRS, bm) for mIn and Allocation.createTyped(mRS, mIn.getType()) for mOut – Paul LeBeau Aug 06 '13 at 21:25
  • I just tried reverting back to exactly what the HelloCompute example does (createFromBitmap(mRS, maskedContent,Allocation.MipmapControl.MIPMAP_NONE,Allocation.USAGE_SCRIPT)) but it made no difference. – Paul LeBeau Aug 06 '13 at 21:28
  • it may be the suspect you thought, seems like a pre-multiplication pixel issue, and also could be an issue of 4.3, have you tried with below api levels, succh as 4.2.2 or 4.1.2 ? – Onur A. Aug 06 '13 at 21:32
  • Just found a 4.2.1 device. I am getting the same result (red pixel ends up black). – Paul LeBeau Aug 06 '13 at 22:17
  • Apparently it must be me doing something wrong because Romain Guy just closed my bug report (http://goo.gl/rmSdA0). Unfortunately it was without any explanation, so I am still in the dark. – Paul LeBeau Aug 06 '13 at 22:41

1 Answers1

3

The example works fine because the example does not modify alpha.

If you are going to modify alpha and then use the Allocation as a normal bitmap you should return (r*a, g*a, b*a, a).

However, if you were sending the Allocation to a GL surface which is not pre-multiplied, your code would work as-is.

R. Jason Sams
  • 1,469
  • 9
  • 10