4. GDI+ Bitmap aus Puffer lesen?

GDI+ Bitmap aus Puffer lesen?

  • N

    Hallo,

    ich möchte RGB-Informationen aus einem Puffer in ein GDIPlus Bitmap einlesen, folgenden Code verwende ich hier:

    int* pBuffer // <-- üsprünglicher Puffer

int sizeX //Breite
int sizeY //Höhe

    Die Informationen liegen jeweils immer auf dem ersten Byte des Integers (4 Byte), also interpretiere ich den Puffer als Folge von Bytes(->castBuffer).

    BYTE* castBuffer=reinterpret_cast<BYTE*>(pBuffer);

    Der Zielpuffer soll je ein Byte pro Farbkanal(RGB) erhalten also ergibt sich seine Länge wie folgt:

    int buflen =sizeX*sizeY*3;
BYTE* byteBuffer= new BYTE[buflen];

    In der Folgenden Schleife kopiere ich nun die relevanten Inhalte von "castBuffer", indem ich jedes 4. Byte lese:

    for (int k=0; k < buflen; k++)
{
	byteBuffer[k]=castBuffer[k*4];
}

    Anscließend erzeuge Ich ein neues GDIPlus::Bitmap aus dem Puffer:

    m_Bitmap= new Bitmap(sizeX,sizeY,sizeX*3,PixelFormat24bppRGB,byteBuffer);

    Dieses Bitmap lässt sich weder anzeigen, noch korrekt speichern.
    Setze ich aber in der Schleife alle Pufferzellen beispielsweise auf 0 wird ein korrektes Bild gespeichert und angezeigt.

    Wo könnte mein Fehler liegen?

    0
  • C

    Na so wie ich das sehe stimmt da auch was an deiner Konvertierung nicht, denn du kannst doch nicht einfach das eine Byte aus deiner Quelle auf die 3 byte im Ziel zuweisen. Du mußt das doch sicher mal auf die 3 Byte also eins Pro Farbkanal aufteilen, oder hab ich da irgendwie ein Denkfehler.

    Da ich jetzt nicht weis wie die Source aufgebaut ist (ich nehm mal an Indexbasierend auf einer Farbtabelle), also mußt du doch die Farbtabelle nehmen und die werte die an der position für RGB stehen in das entsprechende Byte deines Zieles schreiben.

    Wobei deine Quelle eh komisch ist, weil die 4 Byte verbrauchen aber nur 1 Byte genutzt wird, also ist die Bildgröße mal 3 Sinnlos vergäudeter Speicherplatz.

    0
  • N

    Naja die Quelle wird von der DICOM-Bibliothek "IMEBRA" generiert, und enthält die RGB-Werte für jeweils ein Pixel als 3 aufeinanderfolgende Integer (Integer-->liegt bestimmt an der max. Farbtiefe, die DICOM unterstützt),

    dann wird das nächste Pixel abgebildet etc..

    Der originale Puffer sieht in etwa so aus:

    R  R  R  R  G  G  G  G  B  B  B  B  R  R  R  R
0x0000000: 22 00 00 00 C4 00 00 00 21 00 00 00 22 00 00 00
           G  G  G  G  B  B  B  B  R  R  R  R  G  G  G  G
0x0000010: C4 00 00 00 21 00 00 00 34 00 00 00 B8 00 00 00

...

    Das kürze Ich mir quasi auf:

    R  G  B  R  G  B  R  G
0x000000: 22 C4 21 22 C4 21 34 B8 ...

    So schaut das zumindest aus wenn ich mir die Puffer mal im Binärmodus rausschreib.

    Meines Wissens wird das durch den Konstruktor von GDIPlius::Bitmap auch dementsprechend eingelesen, man gibt ja die dimensionen mit, sowie den "stride" also den Zeilenvorschub nach "scanX*3" gelesenen Bytes (Breite*(RGB)), das Format (24 bits per Pixel RGB) und den Puffer an sich.

    0
Anmelden zum Antworten