BitmapData.getPixel32 Workaround


I started here on the assumption that one could correct the output from getPixel32, to recover the RGB values originally put into a BitmapData object. My last post proves that this is impossible.

In short, unless your alpha channel is FF, getPixel32 returns only approximations of the RGB data, in the worse case, where alpha = 00, the RGB values are all zero.

In visual terms, the results from getPixel32 become more posterised the further away from FF the alpha goes - flatlining at alpha = zero.

**See the attached image of two faces. The one on the left was extracted from a bitmapdata object where the alpha was 0xFF, while the one on the right was extracted from a bitmapdata object where the alpha was 0x02. In both cases the original RGB was the same - but the one on the right has lost a lot of RGB information.

Visually the difference begins to become apparent around alpha = 0x0A.
Note also that the alpha returned by getPixel32 is in 2’s complement form, so you need to add 256 to it, or use the operation: [FONT=Courier New]~(alpha-1)[/FONT] [/COLOR][COLOR=Blue]- if you want to see it in non-complement form. [/COLOR]

I posted this under Flash CS3 but here is probably a better place.

No, I don’t have the answer.

But I know there must be an answer. [COLOR=Red]<-- but there isn’t[/COLOR]

I’ve done the following in a loop over many iterations

input = random(256256256*256);
output = bmd.getPixel32(0,0);

I know that if the alpha channel of the input is 0xFF, then output equals input
I also know that if the alpha channel is 0x00, I’ve never got output to equal input.

After random sampling over many iterations I’ve managed to obtain a statistical graph of how often output == input, as a function of the Alpha channel.

And there is a definite pattern there.

Attached is a graph of such.

So there must be some way of transforming the output from getPixel32 back to the value that was put in via setPixel32 [COLOR=Red]<-- but there isn’t[/COLOR]

Note the loglike curve of the peaks and the modulations. That’s not representative of random data nor missing data. [COLOR=Red]<-- but in fact it is (of missing data)[/COLOR]