GetDIBits und Schleife über die Pixel mit X -, Y -

Ich packte einen Teil des Bildschirms und Scannen durch die Pixel einer bestimmten Farbe Palette.

Schaute ich MSDN-das Erfassen eines Abbilds Beispiel und wissen, wie Sie die Funktionen nutzen.

Bekomme ich die bits in ein array, aber ich bin mir nicht sicher, wie es zu tun in einer Weise, die ich Durchlaufen und es als würde ich ein Bild. Ein pseudo-Beispiel (dessen bin ich mir sicher, ist Weg):

for ( x = 1; x <= Image.Width; x += 3 )
{
    for ( y = 1; y <= Image.Height; y += 3 )
    {
        red = lpPixels[x];
        green = lpPixels[x + 1];
        blue = lpPixels[x + 2];
    }
}

Ist im Grunde, was ich tun will, also wenn rot, blau und grün ist eine bestimmte Farbe, ich werde wissen, was zu koordinieren ist es bei (x, y) im Bild.

Ich weiß nur nicht, wie zu verwenden GetDIBits in einer solchen Art und Weise, und wie, um das setup das array entsprechend in der Lage sein, dies zu erreichen.

InformationsquelleAutor guitar- | 2010-09-10

c++getdibits loops pixels

12

Abgesehen von den guten Antworten, die bereits gegeben wurde, hier ein Beispiel von wie, um eine einfache array-Struktur den Fuß auf. (Sie können z.B. Goz' code für die iteration.)

GetDIBits Referenz @ MSDN

Wählen Sie DIB_RGB_COLORS als flag für uUsage und einrichten der BITMAPINFO - Struktur und die BITMAPINFOHEADER - Struktur es enthält. Wenn Sie biClrUsed und biClrImportant null, es gibt "keine" Farbe-Tabelle, so dass Sie können Lesen Sie die Pixel der bitmap erhalten Sie von GetDIBits als eine Folge der RGB-Werte. Mit 32 als bit-Anzahl (biBitCount) stellt die Daten-Struktur nach MSDN:

Das bitmap hat maximal 2^32 Farben. Wenn die biCompression Mitglied der BITMAPINFOHEADER ist BI_RGB, die bmiColors Mitglied BITMAPINFO ist NULL. Jeder DWORD im bitmap-array stellt den relativen Intensitäten von blau, grün und rot, die jeweils für ein pixel. Das high-byte in jedem DWORD wird nicht verwendet.

Da ein MS LONG ist genau 32 bit lang (von der Größe eines DWORD), die Sie nicht haben, um die Aufmerksamkeit auf die Polsterung (wie beschrieben in der Abschnitt "Anmerkungen").

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
```
- Im code gibt es eine fehlende Anweisung, die initialisiert zu MyBMInfo .bmiHeader.biSize = sizeof(MyBMInfo );
- Du hast Recht, vielen Dank für das Auffinden des Fehlers. Ich denke, es ist nun fest, ich zog die Initialisierung vor dem ersten Aufruf von GetDIBits; AFAIK ist es nicht notwendig, re-initialisieren nach dem ersten Aufruf.
- Hmmm. Ich bin da nicht so sicher. Ich habe versucht, dies in meinen code und wenn ich den zweiten Aufruf von GetDIBits bekomme ich eine Fehlermeldung, dass die lokale Struktur wird ein buffer Overflow auf dem stack... ich endlich wieder auf eine Lösung, habe ich das initialisieren Sie die Struktur manuell. In einigen Fällen, die Sie nicht wollen, um eine Kompression. Resuing die informatiuon wiederverwenden wird die Kompression... ich bin nicht sicher, ob dies in Erfüllung Geht. Aber ich hatte keine Zeit um dies zu überprüfen weiter.
- Super Antwort, sehr hilfreich. Aber ich hatte zu entfernen die Anfrage für 32bit, ansonsten die 2. GetDIBits-Aufruf fehlgeschlagen. Keine Ahnung warum 🙂
- Ich hatte das gleiche problem. Nach dem 1. Anruf biCompression auf 3 gesetzt ist, so wird der Wert auf 0 ist notwendig, um zu vermeiden, extra 3 DWORDs geschrieben werden, am Ende der Struktur.
- Leider, ich habe nicht eine Windows-Entwicklungsumgebung mehr zu pflegen, diese zu beantworten. Wenn ich mich Recht erinnere, und schaute Jim Mischel mit ein ist Antwort, 24 bit kann (oder auch nicht) bedeuten Polsterung. Laut MSDN-Website, die biHeight negativ sein kann, je nach Speicher-layout des ursprünglichen DIB.
InformationsquelleAutor
9

GetDIBits gibt ein eindimensionales array von Werten. Für eine bitmap, die M Pixel breit und N Pixel hoch und verwendet 24-bit-Farbe, die ersten (M*3) Byte die erste Zeile von Pixeln. Werden können, gefolgt von ein paar padding bytes. Es hängt von der BITMAPINFOHEADER. Es ist in der Regel Polsterung, um die Breite ein Vielfaches von 4 bytes. Also, wenn Ihr bitmap ist 33 Pixel breit, es wird tatsächlich (36*3) bytes pro Zeile.

Diese "Pixel plus Polsterung" heißt der "stride". Für RGB-bitmaps, können Sie berechnen, Schrittlänge mit: stride = (biWidth * (biBitCount /8) + 3) & ~3, wo biWidth und biBitCount sind entnommen aus dem BITMAPINFOHEADER.

Ich bin mir nicht sicher, wie Sie Sie möchten, Durchlaufen das array. Wenn Sie gehen wollen pixel-by-pixel von oben Links nach unten rechts (vorausgesetzt, diese ist ein top-down-bitmap):
```
for (row = 0; row < Image.Height; ++row)
{
    int rowBase = row*stride;
    for (col = 0; col < Image.Width; ++col)
    {
        red = lpPixels[rowBase + col];
        //etc.
    }
}
```
- huh das ist schrecklich <code>Schritt = (biWidth * (biBitCount / 8) + 3) & ~3</code> - hat mich eine Weile, um zu verstehen, (die Runden bis zum nächsten LONG = 4 [Byte]). Aber eine einfache Möglichkeit, um die Aufmerksamkeit auf Polsterung, wenn Sie zu haben.
- schließlich ein Beispiel, nimmt die Schrittlänge berücksichtigt...anstatt dass eine Konvertierung in 32 bit zu erst 🙂
InformationsquelleAutor Jim Mischel
2

Es ist nicht so einfach. Ihr Algorithmus hängt von der Farbtiefe des Bildes. Wenn es 256 oder weniger, Sie haben nicht pixel-Farben, aber indeces in einer palette von Farben. 16-bit-Pixel werden könnte, RGB555 oder RGB565, 24-bit-Bilder werden RGB888, und 32-bit-Bilder werden mit RGBA-oder ARGB. Sie müssen die BITMAPINFOHEADER, um das herauszufinden.

Sobald Sie herausfinden, die pixel-Daten wird nur ein array der Größe Breite * Höhe * (BitsPerPixel /8)
- +1. Alternativ können Sie versuchen zu kopieren/blit, um ein bitmap mit festen/bekannten Farbtiefe.
- Ich denke, die OP wählt das bitmap in den DeviceContext, so hat Vollzugriff auf die bitmap. Mit 24 bit und keine Kompression erlauben, es zu Lesen, als RGB888 leicht.
InformationsquelleAutor James
2

In dem link, den Sie posten, erstellen Sie ein 32-bit-bitmap-so nehme ich an, dass Sie beim Lesen eines 32-bit-bitmap (Diese Annahme kann falsch sein).

Daher ändern Sie Ihre Schleife um die folgenden arbeiten sollten:
```
char* pCurrPixel = (char*)lpPixels;
for ( y = 0; y < Image.Height; y++ )
{
    for ( x = 0; x < Image.Width; x++ )
    {
        red = pCurrPixel[0];
        green = pCurrPixel[1];
        blue = pCurrPixel[2];

        pCurrPixel += 4;
    }
}
```
Dinge zu beachten:

1.Arrays sind 0-basiert in C/C++

2. Sie wurden stepping 3 Pixel horizontal und vertikal jeder Zeit. Was bedeutete, dass Sie nicht besuchen jedes pixel.

3. Eine bitmap ist in der Regel so organisiert, dass es "Höhe" erstreckt sich von "Breite" Pixel. Deshalb sollten Sie Schritt für Schritt durch die einzelnen pixel in einen Bereich, und bewegen Sie dann zum nächsten span.

4. Wie bereits darauf hingewiesen, stellen Sie sicher, aare Lesen von Pixeln korrekt. in 16-bit-Modus mehr komplexe

InformationsquelleAutor Goz
0

Manche überraschung aus dem MSDN:

Die Tabelle besteht aus einem array von RGBQUAD Datenstrukturen. (Die Tabelle
für die BITMAPCOREINFO-format ist gebaut mit die Daten RGBTRIPLE
Struktur.) Rot, grün und blau bytes sind in umgekehrter Reihenfolge (red
swaps position mit blau) von der Windows-Konvention.

so, die Farben sind in BGR Reihenfolge im Speicher nach dem GetDIBits()

InformationsquelleAutor Крутой Инфо

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.