[Prob] DIB Bitmap aus Scanner (Twain-Quelle) korrekt speichern



  • Hallo an alle - ich bin der Neue 🙂
    Geistere hier schon länger rum, jetzt hab ich mich mal angemeldet...

    Ich habe folgendes Problem:

    ich habe eine Klasse, die mir per TWAIN etwas einscannt.
    Das Scannen an sich klappt wunderbar, ich kann den Scanenr ansteuern, er scannt und es befindet sich anscheinend ein Bitmap als DIB (device independent bitmap) im Speicher.

    Per Sendmessage sende ich beim TWAIN State 7 - wenn case TWRC_XFERDONE erreicht wurde - folgendes an meine Nachrichtenschleife:

    SendMessage(hWnd, WM_TW_IMAGE, 0, hBitmap);
    

    Sendmessage müsste hier ja korrekt aufgerufen worden sein, denn ich erhalte wirklich in der WindowMessage eine Nachricht, dass ein Handle auf ein Bitmap auf mich wartet 🙂

    Über

    ostringstream xyz;
     xyz<< lParam;
     MessageBox(NULL,xyz.str().c_str(),"Ausgabe lParam",MB_OK);
    

    bekomme ich die Handle-Nummer des lParams...Alles schein i.O.

    Nun will ich das Bitmap speichern - und jetzt meine Frage - wo ist der fehler begraben?

    // Infoheader
    	BITMAPINFO infoheader;
    	infoheader.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
    	infoheader.bmiHeader.biWidth = 500; // Breite in Pixeln
    	infoheader.bmiHeader.biHeight = 500; // Höhe in Pixeln
    	infoheader.bmiHeader.biPlanes = 1;
    	infoheader.bmiHeader.biBitCount = 24; // Farbtiefe in bits
    	infoheader.bmiHeader.biCompression = 0;
    	infoheader.bmiHeader.biSizeImage = 0;
    	infoheader.bmiHeader.biXPelsPerMeter = 0;
    	infoheader.bmiHeader.biYPelsPerMeter = 0;
    	infoheader.bmiHeader.biClrUsed = 0;
    	infoheader.bmiHeader.biClrImportant = 0;
    
    // Platz für die Pixeldaten reservieren
    	int* bitmap = new int[500*500*3]; // Breite*Höhe*Farbtiefe (Bytes)
    
    // Fileheader
    	BITMAPFILEHEADER fileheader;
    	fileheader.bfType = 19778; // 'BM'
    	fileheader.bfSize = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + sizeof(bitmap); // Gesamtgröße der Datei
    	fileheader.bfReserved1 = 0;
    	fileheader.bfReserved2 = 0;
    	fileheader.bfOffBits = sizeof(BITMAPFILEHEADER) +   sizeof(BITMAPINFOHEADER); // ab hier Pixel
    
    // Die Pixeldaten aus der hbitmap in bitmap kopieren
    HDC dc  = CreateDC(NULL, NULL, NULL, NULL);
    HDC mem = CreateCompatibleDC(dc);
    
    // Create a bitmap and link it to the memory dc
    HBITMAP hbitmap = CreateCompatibleBitmap(dc, 500, 500);
    
    if (GetDIBits(mem, (HBITMAP)lParam, 0, 500, bitmap, (BITMAPINFO*)&infoheader, DIB_RGB_COLORS)==0)
    MessageBox(NULL,"fehler","fehler0",MB_OK); // hier gibt er fehler aus 
    
    // Eine neue Datei erstellen bzw eine bestehende öffnen
    HANDLE hfile = CreateFile("d:\\cmap.bmp", GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, 0, 0);
    
    // Die Daten in die Datei schreiben
    DWORD dummy;
    WriteFile(hfile, &fileheader, 14, &dummy, NULL);
    WriteFile(hfile, &infoheader, 40, &dummy, NULL);
    WriteFile(hfile, bitmap, 750000, &dummy, NULL);
    
    // Aufräumen
    DeleteObject(hbitmap);
    ReleaseDC(hWnd, dc);
    CloseHandle(hfile);
    

    Nun seid ihr dran - woran könnts liegen?
    Oder seh ich vor Code den Wald nicht 🙂



  • nicht dass jemand denkt, ich sei nicht registriert.....
    hier bin ich - das klappte anscheinend nicht so wie ich dachte



  • es wäre noch hilfreich, wenn du den konkreten fehler beschreibst - passiert nix? speichert er nix? schmiert er ab? fehlermeldung?



  • Oh ja Martin,

    die Fehlerbeschreibung hab ich ganz vergessen.
    Also er erstellt eine Bitmap-Datei, die aber komplett grau ist.
    Sprich, er füllt die Bitmap nicht korrekt.

    Ich weiss halt nicht wirklich, ob die DIB-Bitmap korrekt ist.
    Laut der TWAIN-Dokumentation ist das Bitmap am Ende des Scanvorgangs (wenn TWRC_XFERDONE erreicht wurde) eindeutig eine Native DIB....

    Kann man vielleicht testen, ob das Handle, welches ich habe, überhaubt korrekt ankam? Und ist GetDIBits auch die richtige Wahl um das Bitmap umzuformen?

    Also laut Fehler - und das ist es ja wenn GetDIBits = 0 ist, kann also nur da liegen.

    Aber was ist die Lösung - danke fürs lesen 🙂


Anmelden zum Antworten