HBITMAP Alpha

[AltPluzF4]

I'm trying to compare images, but the alpha is making the comparison fail (even if the rgb are correct)


BITMAP large;
GetObject(hScreen, sizeof(BITMAP), &large);
int lBps = large.bmBitsPixel / 8;
int lSize = large.bmHeight * large.bmWidth * lBps;
BYTE *lBytes = new BYTE[lSize];
GetBitmapBits(hScreen, lSize, lBytes);


Is what I'm using to get the bytes of the image.
I've been able to solve this by a cheap little hack:

for (int z = 3; z < lSize-4; z+=4)
lBytes[z] = 0;


However, I'm curious... what would be the best way to do this? I'm getting the HBITMAP via CreateCompatabileBitmap and BitBlt'ing the image to it with SRCCOPY.

Again, my problem has been solved by the simple for loop, and everything works fine. I'm just curious if there's a better method.

Thanks for any input.

[VladimirF]

... I'm just curious if there's a better method.Better than what? You didn't show HOW you compare these images.

[AltPluzF4]

I was asking if there was a better way to remove the alpha from the image.

As far as comparing, I am using memcmp, while the loaded image is always 00 on the alpha of each pixel.

[VladimirF]

I was asking if there was a better way to remove the alpha from the image.Got you. Sorry for misunderstanding.
Since 32-bit processors are oriented to work with 32-bit values (not bytes), it might be better to use int in your loop:
for(int* p = (int*)lBytes, int i = 0; i < lSize/4; ++i, ++p)
*p &= 0x00ffffff;(or something like that).

[VladimirF]

If you didn’t take my advise yet – don’t.
I have violated my own rule of not compiting with modern compilers in optimization.
Here is a Release (optimized for speed) build’s disassembly:
int main()
{
size_t lSize = 100000000;
unsigned char* lBytes = (unsigned char*)malloc(lSize);
00401000 push 5F5E100h
00401005 call dword ptr [__imp__malloc (4020A0h)]
0040100B add esp,4
size_t i = 0;
0040100E add eax,3
00401011 mov ecx,17D7840h
for(int* p = (int*)lBytes; i < lSize/4; ++i, ++p)
*p &= 0x00ffffff;
00401016 mov byte ptr [eax],0
00401019 add eax,4
0040101C sub ecx,1
0040101F jne main+16h (401016h)
return 0;
00401021 xor eax,eax
}
00401023 ret As you can see, the compiler turned my “clever” code into what you had at the beginning…
Well, that wasn’t as big a surprise as that there was no difference in the compiled code even when I enabled Streaming SIMD Extensions (/arch:SSE) or Streaming SIMD Extensions 2 (/arch:SSE2).
I was really hopping to see some interesting generated code :(