PixelFormat.Format32bppArgb seems to have wrong byte order

笑着哭i 提交于 2019-11-28 07:24:57

Pixel data is ARGB, 1 byte for alpha, 1 for red, 1 for green, 1 for blue. Alpha is the most significant byte, blue is the least significant. On a little-endian machine, like yours and many others, the little end is stored first so the byte order is bb gg rr aa. So 0 0 255 255 equals blue = 0, green = 0, red = 255, alpha = 255. That's red.

This endian-ness order detail disappears when you cast bd.Scan0 to an int* (pointer-to-integer) since integers are stored little-endian as well.

In Bpp32Argb pixel format. You dont' need to byte-by-byte access.

Trun Scan0 to an Int32 pointer in unsafe context.

unsafe
{
    var ptr=(int*)bmData.Scan0;
}

You can do some bit operation like below To access color channels of first pixel.

And dont need to care byte-order.

var a=(ptr[0] & 0xFF000000)>>24;
var r=(ptr[0] & 0x00FF0000)>>16;
var g=(ptr[0] & 0x0000FF00)>>8;
var b=(ptr[0] & 0x000000FF);

BTW you can work with Color.ToArgb() returned int easily.

AFAIK it is technically based on COLORREF (which is used in Windows GDI/GDI+ everywhere) and that is stored RGBA in memory... see http://msdn.microsoft.com/en-us/library/dd183449%28VS.85%29.aspx

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!