|
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
braesident
Anmeldungsdatum: 15.04.2008 Beiträge: 189 Wohnort: Berlin
|
Verfasst am: 19.03.2016, 22:02 Titel: BITMAPINFOHEADER Phänomen |
|
|
Hallo Leute.
Also folgender Code funktioniert bei mir in der Schule problemlos, doch auf meinem privaten PC gibt es (ich sag mal) Pixelverschiebungen. Nach langem probieren hab ich heraus gefunden das sich dieses verhalten beheben lässt indem ich bei dem BitMapInfoHeader.WITDH die BMP breite +2 angebe.
Doch ich denke diese Lösung kann doch nicht richtig sein und es muss ja eine Ursache dafür geben das diese Verschiebung zu stande kommt ?!
System Schule: quadCore 64bit Win7 Pro 16GB Ram
dieses System: dualCore 64bit Win7 Pro 8GB Ram
im Verdacht hab ich noch die Funktion GetDIBits die diese Bmp in ein FB-Image kopiert.
Edit: Fehlerbild links richtig / rechts falsch
Code: | #Include Once "windows.bi"
#include Once "win\shellapi.bi"
#include Once "fbgfx.bi"
ScreenRes 300 , 300 , 32
dim as any ptr speicher = ImageCreate( 250, 250 , &hb7b7b7 )
Dim as HWND mHwnd
ScreenControl( FB.GET_WINDOW_HANDLE, cast(integer,mHwnd) )
'' BitMap erstellen
Dim As HDC mHdc = GetDC(mHwnd)
Dim As HDC hdcComp = CreateCompatibleDC(mHdc)
Dim As HBITMAP bitmap = CreateCompatibleBitmap( mHdc , 250 , 250 )
Dim as BITMAPINFO bmi
With bmi.bmiHeader
.biSize = SizeOf(BITMAPINFOHEADER)
.biWidth = 252 'breite
.biHeight = -250 '-hoehe (sonst Kopfstand)
.biPlanes = 1
.biCompression = BI_RGB
.biBitCount = 32
End With
Dim As hbrush mBrush = createSolidBrush(BGRA( 255, 127, 0, 0 ))
'' bearbeite BMP
SelectObject( hdcComp , bitmap )
rectangle( hdcComp , 0, 0, 249, 249 )
SelectObject( hdcComp , mBrush )
ExtFloodFill( hdcComp , 125 , 125 , BGR(255,255,255) , FLOODFILLSURFACE ) ''alles weisse soll in Farbe von mBrush werden
'' fbImage erstellen
? GetDIBits( hdcComp, bitmap, 0, 250, speicher + 32, @bmi, DIB_RGB_COLORS)
Line speicher, (10,10)-Step(50,50),&h0000ff,b
ReleaseDC( mHwnd , mHdc )
DeleteObject(mBrush)
DeleteDC(hdcComp)
DeleteObject(bitmap)
screenLock
put(25,25),speicher,pset
screenUnlock
imagedestroy speicher
getKey
|
_________________ FBIde: 0.4.6
fbc: FreeBASIC Compiler - Version 1.05.0 (01-31-2016), built for win64 (64bit)
OS: Windows NT 6.2 (build 9200)
Zuletzt bearbeitet von braesident am 19.03.2016, 22:54, insgesamt einmal bearbeitet |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 19.03.2016, 22:31 Titel: |
|
|
Wenn die Bildbreite nicht durch 4 teilbar ist, wird die Sache etwas komplizierter, weil du den/die/das(?) Pitch berücksichtigen musst. Ob das bei verschiedenen Systemen unterschiedlich aussehen kann, kann ich dir allerdings nicht sagen. Würde mich zwar wundern, kann ich aber nicht ausschließen.
Siehe dazu auch SCREENINFO. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
braesident
Anmeldungsdatum: 15.04.2008 Beiträge: 189 Wohnort: Berlin
|
Verfasst am: 19.03.2016, 23:03 Titel: |
|
|
danke nemored.
Deine Bedenken sind schon richtig. Ursprünglich bezog sich meine Grafik auf die Auflösung. Mein System hat 1366 was ein Rest 2 ergibt. In der Schule hab ich eine wesentlich höhere Auflösung (welche ich jetzt aber nicht im Kopf hab) die warscheinlich durch 4 teilbar ist.
Ich hab oben nochmal für andere die dieses Problem mal haben werden noch ein Link gepostet mit meinem Fehlerbild. _________________ FBIde: 0.4.6
fbc: FreeBASIC Compiler - Version 1.05.0 (01-31-2016), built for win64 (64bit)
OS: Windows NT 6.2 (build 9200) |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 19.03.2016, 23:36 Titel: |
|
|
Ich hatte so ein "Verschiebeproblem" auch, und zwar bei der Schriftausgabe mit FreeType, wenn ich mit allgemeinen Bildpuffern arbeiten möchte - weil mir das zu viel Gepfriemel war, habe ich dann die Breite des Ausgabepuffers immer auf ein Vielfaches von 4 erweitert. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
St_W
Anmeldungsdatum: 22.07.2007 Beiträge: 949 Wohnort: Austria
|
Verfasst am: 21.03.2016, 02:30 Titel: |
|
|
Das "Phänomen" ist ganz leicht erklärbar.
Der Grund für dein Problem ist, dass FB eine Bild-Zeile aus Daten + optionalem Padding besteht. In deinem Fall mit der Breite 250 Pixel werden von meiner FB Version 2 padding bytes hinzugefügt, damit die Daten im Speicher "angenehmer" ausgerichtet sind.
Das Problem ist dein abenteuerlicher Programmierstil, der sehr stark von FB-Interna abhängig ist und schnell kaputt sein wird, wenn sich auch nur eine Kleinigkeit z.B. am FB.IMAGE Datenformat ändert. Optimalerweise sollte man wohl ImageInfo verwenden, um die entsprechenden Daten und Pointer des FB.IMAGE auszulesen. Zumindest aber die Struktur, wie sie in der fbgfx.bi definiert ist.
Du deklarierst also das FB.Image nicht als any ptr, sondern als FB.IMAGE. Anstatt bmi.bmiHeader.biWidth willkürlich auf 252 zu setzen, verwendest du "speicher->pitch \ speicher->bpp". Das "speicher + 32" (!) ersetzt du durch "speicher+1" (Pointer Arithmetik) or noch besser ermittelst du den Pointer via ImageInfo Aufruf.
nemored hat Folgendes geschrieben: | Ich hatte so ein "Verschiebeproblem" auch, und zwar bei der Schriftausgabe mit FreeType, wenn ich mit allgemeinen Bildpuffern arbeiten möchte - weil mir das zu viel Gepfriemel war, habe ich dann die Breite des Ausgabepuffers immer auf ein Vielfaches von 4 erweitert. |
Man sollte sich nicht darauf verlassen, dass FB immer auf Vielfache von 4 erweitert, sondern besser die tatsächliche Bild-Zeilenlänge (Pitch) ermitteln. Denn falls sich dieses Implementierungsdetail in der gfxlib2 einmal ändern sollte funktioniert dein Programm nicht mehr richtig. _________________ Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 21.03.2016, 02:42 Titel: |
|
|
FB.Image enthält bereits alle Daten zu Höhe, Breite, Bpp und Pitch im Header. Mit FB.Image PTR statt ANY PTR hat man damit schon Zugriff zu allen Daten. Mit IMAGEINFO kann man dann noch weitere Details herausziehen.
Zitat: | Man sollte sich nicht darauf verlassen, dass FB immer auf Vielfache von 4 erweitert, sondern besser die tatsächliche Zeilen-Puffer-Größe (Pitch) ermitteln. |
Da hast du vielleicht Recht, aber mein Versuch, mit dem Pitch zu arbeiten, hat genauso viel Chaos angerichtet wie das Arbeiten ohne Pitch. Ich könnte höchstens stattdessen den Bildspeicher auf die Größe des Pitch erweitern, aber ohne Vergrößerung wird das bei mir nichts. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
noop
Anmeldungsdatum: 04.05.2005 Beiträge: 259
|
Verfasst am: 23.03.2016, 16:33 Titel: |
|
|
Ich habe mich gerade mit Ähnlichem beschäftigt. Mein Goto-Makro ist
Code: | #define getPixelAddress(img,row,col) cast(any ptr,img) + _
sizeof(FB.IMAGE) + (img)->pitch * (row) + (img)->bpp * (col) |
Wendet man getDIBits auf einen temporären Buffer an, dann kann man anschließend in einer Schleife, inklusive Padding, den Buffer in ein Bild schreiben.
Code: | for y as integer = 0 to h-1
for x as integer = 0 to w-1
dim as const ulong colour = buffer[x+y*w]
dim as ulong ptr pa = getPixelAddress(img,y,x)
*pa = colour
next x
next y | Habe den Code nicht extra getestet. So ähnlich sollte es aber funktionieren. |
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|