GetDIBits et boucle sur les pixels à l'aide de X, Y

Outre les bonnes réponses déjà données, voici un exemple de comment pour obtenir une simple structure de tableau pour la marche. (Vous pouvez utiliser, par exemple, Goz' code pour l'itération.)

GetDIBits de référence @ MSDN

Vous devez sélectionner DIB_RGB_COLORS comme drapeau pour uUsage et configurer le BITMAPINFO de la structure et la BITMAPINFOHEADER de la structure qu'il contient. Lorsque vous définissez biClrUsed et biClrImportant à zéro, il n'y a "pas" de la table des couleurs, ainsi vous pouvez lire les pixels de l'image bitmap que vous obtenez à partir GetDIBits comme une séquence de valeurs RVB. À l'aide de 32 comme le nombre de bits (biBitCount) définit la structure de données selon la MSDN:

L'image a un maximum de 2^32 couleurs. Si le biCompression membre de la BITMAPINFOHEADER est BI_RGB, le bmiColors membre de BITMAPINFO est NULL. Chaque DWORD dans le bitmap tableau représente les intensités relatives de bleu, de vert et de rouge, respectivement, pour un pixel. L'octet de poids fort de chaque DWORD n'est pas utilisé.

Depuis un MS LONG est exactement 32 bits de long (de la taille d'un DWORD), vous n'avez pas à payer l'attention sur le rembourrage (comme décrit dans la Section remarques).

Code:

HDC hdcSource = NULL; //the source device context
HBITMAP hSource = NULL; //the bitmap selected into the device context

BITMAPINFO MyBMInfo = {0};
MyBMInfo.bmiHeader.biSize = sizeof(MyBMInfo.bmiHeader);

//Get the BITMAPINFO structure from the bitmap
if(0 == GetDIBits(hdcSource, hSource, 0, 0, NULL, &MyBMInfo, DIB_RGB_COLORS))
{
    //error handling
}

//create the pixel buffer
BYTE* lpPixels = new BYTE[MyBMInfo.bmiHeader.biSizeImage];

//We'll change the received BITMAPINFOHEADER to request the data in a
//32 bit RGB format (and not upside-down) so that we can iterate over
//the pixels easily. 

//requesting a 32 bit image means that no stride/padding will be necessary,
//although it always contains an (possibly unused) alpha channel
MyBMInfo.bmiHeader.biBitCount = 32;
MyBMInfo.bmiHeader.biCompression = BI_RGB;  //no compression -> easier to use
//correct the bottom-up ordering of lines (abs is in cstdblib and stdlib.h)
MyBMInfo.bmiHeader.biHeight = abs(MyBMInfo.bmiHeader.biHeight);

//Call GetDIBits a second time, this time to (format and) store the actual
//bitmap data (the "pixels") in the buffer lpPixels
if(0 == GetDIBits(hdcSource, hSource, 0, MyBMInfo.bmiHeader.biHeight,
                  lpPixels, &MyBMInfo, DIB_RGB_COLORS))
{
    //error handling
}
//clean up: deselect bitmap from device context, close handles, delete buffer

OriginalL'auteur

Il n'est pas si facile. Votre algorithme dépendra de la profondeur de couleur de l'image. Si c'est de 256 ou moins, vous n'aurez pas de pixel de couleurs, mais des indices dans une palette de couleurs. Pixels 16 bits pourrait être RGB555 ou RGB565, les images 24 bits sera RGB888, et les images 32 bits sera RGBA ou ARGB. Vous aurez besoin de la BITMAPINFOHEADER pour le savoir.

Une fois que vous découvrez, les données de pixel sera juste un tableau de taille largeur * hauteur * (BitsPerPixel /8)

OriginalL'auteur James

Une certaine surprise de MSDN:

La table se compose d'un tableau de RGBQUAD structures de données. (Le tableau
pour le BITMAPCOREINFO format est construit avec la RGBTRIPLE de données
structure.) Rouge, vert et bleu octets sont dans l'ordre inverse (rouge
swaps position avec le bleu) à partir de la Windows convention.

donc, les couleurs sont dans BGR ordre dans la mémoire après GetDIBits()

OriginalL'auteur Крутой Инфо