007
23.09.2005, 00:24 Uhr
CDW
|
Brauchst Du denn CBitmap noch für irgendwas? Du kannst auch bei wotsit.org die BMP Doku ziehen und relativ schnell selber den Header einlesen (und damit auch 24 bit BMPs laden  ).
Hat den Vorteil dass diese Methode ungleich schneller ist, als GetPixel &Co
Ich kann auch einen Beispielcode geben (leider kein C++):
| Code: |
mov pBitmap,InputFile(addr skin_opt.back_path)
mov ebx,pBitmap
mov eax,dword ptr [ebx+12h]
mov ecx,dword ptr [ebx+16h]
mov einstellungen.background_breite,eax
mov einstellungen.background_hoehe,ecx
;checken ob es auch ein 24 bitter ist
add ebx,28
.if byte ptr [ebx]!=18h
invoke MessageBox,hWin,addr falsches_format,addr Fehler,MB_ICONERROR
mov eax,FALSE
ret
.endif
;jetzt Parsen um unsichbarbereiche zu erstellen:
|
also pBitmapt ist die in Memory (als File) gemappte Bitmap - einfach als Anfangszeiger auf den Speicher, wo sie liegt, betrachten.
In Anfangsspeicher+0x12 ist dann die Breite und im Anfagsspeicher+0x16 die Höhe.
Anfagsspeicher+28 (dezimal) die Farbtiefe.
Um die Bitmap wirlich auszulesen, muss man aber beachten, dass es so eine Art "auffülbytes" gibt.
folgendes gilt nur, wenn Du die Bitmap naitiv auslesen möchtest und nur für "bunte" (also mit mehr als 256 Farben, weil diese (256>= farbige) eine Farbpalette haben und nicht direkte Farbangaben und man hier die Doku dann doch lesen muss):
Wenn man die BMP Pixel für Pixel auslesen will, so ließt man z.B in einer Verschachtelten Forschleife die Pixels aus. Ich stelle mir das Bildlich so vor
| Code: |
.....X1..X2..X3
y1..23..45..2
y2..12..33..44
y3 usw
|
Also jeweils RGB Farbwert. Die Stellen rechnet man selber mit (bzw. wird ja in ein Array kopiert.
Die X Reihe wird dabei aufgefüllt:
Breite_der_BMP DIV 4 -> Rest==Auffüllzeichenmenge pro Zeile. Heißt im Klartext
dass man nach dem man seine Breite ausgelsenen hat (was weiß ich, bei einem BMP
von 200x100 wären das 200 Bytes) muss man dann diese Menge überspringen, bevor die
nächste Zeile beginng (sonst kommt nur mist raus).
Wo die Pixels im Speicher anfangen:
Anfagsspeicher+10 == Offset der Pixeldaten
also Anfangsspeicher+ Offset der Pixeldaten zusammenrechnen==Zeiger auf Pixeldaten.
die auszulesende größe ist dann: Breite mal Höhe + Rest(Breite/4)*Höhe
(ist aber egal, wenn man selber die zeilen zählt )
Die Bilddaten liegen übrigens in der BMP *auf dem Kopf* rum. Also nicht erschrecken, wenn das Bild andersrum angezeigt wird - einfach das Einlesen entsprechend anpassen
Ich hoffe es war nicht allzu verwirrend und erleichtert Dir vielleicht das lesen der Doku.
EDIT: warum nimmst Du für 8 Bit WORD und für 16 einen Dword? 8Bit sind ein Byte . Aber die Pixelfarbe an sich ist afiak auch 24 bit. Ein "256 Farben" BMP hat so weit ich weiß nur eine Palette mit 256 Farben - also eine Art Array. Die Farben jedoch sind "vollwertig". Bei 16-Bit auch. Also vielleicht lags daran, dass das Programm abgestürzt ist. Du brauchst auf jedenfall bei Pixelzugriff/Pixelkopie ein DWORD Array. Ich weiß es nicht mehr so genau, ob RGB jetzt wirlich nur 3 Bytes liefert - unter Windows und damit auf x86 Systemen dürfte es ein DWORD sein, weil es Architekturbediengt besseren Speicherzugriff bietet (im sinne von schnelleren)
--
EB FE
Dieser Post wurde am 23.09.2005 um 00:36 Uhr von CDW editiert. |
