对png和bmp进行按位运算会得到不同的结果？ （相同的32位ARGB表示形式）

Question

I'm trying to replicate some image filtering software on the Android platform. The desktop version works with bmps but crashes out on png files.

When I come to xOr two pictures (The 32 bit ints of each corresponding pixel) I get very different results for the two pieces of software.

I'm sure my code isn't wrong as it's such a simple task but here it is;

const int aMask = 0xFF000000;

int xOrPixels(int p1, int p2) {
    return (aMask | (p1 ^ p2) );
}

The definition for the JAI library used by the Java desktop software can be found here and states;

 The destination pixel values are defined by the pseudocode:

 dst[x][y][b] = srcs[0][x][y][b] ^ srcs[1][x][y][b];

Where the b is for band (ie R,G,B).

Any thoughts? I have a similar problem with AND and OR.

Here is an image with the two source images xOr'd at the bottom on Android using a png. The same file as a bitmap xOr'd gives me a bitmap filled with 0xFFFFFFFF (White), no pixels at all. I checked the binary values of the Android ap and it seems right to me....

Gav

NB When i say (Same 32 bit ARGB representation) I mean that android allows you to decode a png file to this format. Whilst this might give room for some error (Is png lossless?) I get completely different colours on the output.

Answer 1

The png could have the wrong gamma or color space, and it's getting converted on load, affecting the result. Some versions of Photoshop had a bug where they saved pngs with the wrong gamma.

Answer 2

What are you doing prior to the code posted?

PNG is a compressed format, using the deflate algorithm (See Section 5 of RFC2083 ), so if you're just doing binary reads, you're not looking at actual pixels.

Answer 3

I checked a couple of values from your screenshot.

The input pixels:

• Upper left corners, 0xc3cbce^0x293029 = 0xeafbe7
• Nape of the neck, 0xbdb221^0x424dd6 = 0xfffff7

are very similar to the corresponding output pixels.

Looks to me like you are XORing two images that are closely related (inverted in each color channel), so, necessarily, the output is near 0xffffff.

If you were to XOR two dissimilar images, perhaps you will get something more like what you expect.

The question is, why do you want to XOR pixel values?