Bitmap unterschiedlich Linux und Windows

[Winni]

Hallo!

Leider hast Du recht: Die Dokumentation von TBGRAbitmap ist lausig.

Es gibt das Einsteiger-Tutorial:

https://wiki.lazarus.freepascal.org/BGR ... utorial/de

Und es gibt ein eigenes Board im internationalen Forum:

https://forum.lazarus.freepascal.org/in ... ,46.0.html

Da taucht circular ab und an auch auf, um Fragen zu beantworten oder gefundene Bugs zu fixen.
Wenn Du Zeit hast, lies die letzten Jahrgänge. Zumindest was interessiert.

Und Lainz als Kopf der BGRAcontrols ist auch oft da.

Winni

[af0815]

Ich weis, ich lese das internationale Forum als auch teilweise die Mailinglisten mit.

Für mich ist Lazarus das tägliche Brot

Wenn ich das BGRABitmap besser durchschauen würde, so wäre es einfacher dort was zum Beitragen.

[aro]

Hallo,

erst mal Grundsätzlich gibt es in Windows auch 32 Bit Grafikformate. Das 4. Byte kann fürs einblenden verwendet werden, oder liegt nur ungenutzt im Speicher.
Dafür kannst Du auf jedes Pixel beim Verschieben oder kopieren als Integer zugreifen, was wesentlich schneller geht. Auch Positionsberechnungen in der Datei sind viel einfacher.

In Delphi habe ich Grafik grundsätzlich als DIBś im 32 Bit - Format gehandelt. Leider wird das Format nicht von allen Grafikprogrammen unterstützt.

Wenn Du das Format der Datenquelle kennst und die Adresse findest ab der die eigentlichen Daten abgelegt sind, dann ist es kein Problem jedes Pixel zu lesen
und in das neue Format zu speichern.

Bitmaps sind dazu aber nicht geeignet, da kann man sich nicht darauf verlassen das beim Speichern wirklich der Datenpuffer verwendet wird.

Bei BGRABitmap's hast Du einen Byte - Pointer (DataByte), den ich meistens als PInteger benutze.

Das klappt ganz gut.

[af0815]

Grundlegend ist es amtlich
TBitmap hat 3 Bytes in Windows und 4 Bytes in Linux.

Wenn man den Thread von Anfang an liest, ist es um diese Problematik gegangen. Ein Programm das unter Windows wunderbar läuft, läuft zum Beispiel Cross-Kompiliert gegen Linux nicht mehr, weil plötzlich das Byteformat sich verschoben hat.

BGRABitmap hat auf allen BS dasselbe Speicherlayout, abhängig was man verwendet. Hier ging es auch noch darum, das der deBayer Algo halt nur mit 3Byte Layout umgehen kann.

Aktuell ist alles gefixt und auch im GIT schön lauffähig.

[wp_xyz]

Grundlegend ist es amtlich
TBitmap hat 3 Bytes in Windows und 4 Bytes in Linux.

Nachdem man unter Windows mit Bitmap.PixelFormat=pf32bit auch 4-byte-Bitmaps haben kann, müsste dann unter Linux nicht auch Bitmap.PixelFormat = pf24bit zu einem 3-byte-Bitmap führen? So wie ich deinen letzten Beitrag verstehe, müsste dein Windows-Programm dann nicht auch unter Linux laufen?

[af0815]

Nein, da die deBayer nur 3 Byte aktuell kann. Und viele von den Routinen, die sich mit Kameras beschäftigen, nur mal 3Bytes haben, weil das so von den meisten USB Kamera ausgegeben wird. V4L zB. aber auch bei gstreamer schon so gesehen. Und das bei USB Kamers von 2MPx bis 20MPx.

[wp_xyz]

Versteh ich nicht. Wenn du nach TBitmap.Create das PixelFormat auf pf24 setzt, hast du doch 3 Byte pro Pixel, egal ob du auf Windows bist oder auf Linux.

[af0815]

Hinterher ist man immer schlauer. BGRABitmap ist jetzt mal das wo ich weiterarbeite.

[Winni]

Hi!

Das entscheidende Argument ist der Unterschied in der Geschwindigkeit.

TBitmap ist ein plattformübergreifender Hybrid, der von Delphi/Windows geerbt wurde. Mit viel Kraft wurde der dann an Linux und Mac angepasst. Wenn man auf jedes Pixel zugreifen muss - und das muss man bei Filtern - so ist der Unterschied gravierend: Bei BGRA ist das Resultat sofort vorhanden, bei TBitmap kannst Du erstmal Kaffe kochen gehen.

Winni

[af0815]

Ich greife, wenn nötig direkt auf die Daten durch. Alles andere wäre zu langsam

Code: Alles auswählen

      BMP.BeginUpdate;
      SRGGB8_to_BGRA(PByte(Buffer), PByte(BMP.RawImage.Data), BMP.Width, BMP.Height);
      BMP.EndUpdate;

Geht ja auch, solange man das mit Begin/Endupdate stabil macht. Und genau da bin ich gestolpert.

Egal ich habe eine Lösung und mit BGRABitmap lässt sich auch ein Weissabgleich vereinfachen und andere Sachen auch. Mehr Infos gibt es dann auch im Englischen Forum, da dort die Entwickler von BGRABitmap sich tummeln

[Winni]

Hi!

Hab gerade den Speed-Test TBitmap gegen TBGRAbitmap gemacht:

200 x 200 pixel, Farbe random, alle Pixel füllen:

TBitmap : 83 ms
TBGRAbitmap: 3 ms

Das ist ein Verhätnis von 27 : 1
Jeder kann sich ausrechnen, welche Zeit das bedeutet, wenn er die Bilder von seiner Super-Duper-Kamera mit einer TBitmap bearbeiten will.

Winni

[wp_xyz]

200 x 200 pixel, Farbe random, alle Pixel füllen:

TBitmap : 83 ms
TBGRAbitmap: 3 ms

Und wie hast du beim TBitmap die Pixel geschrieben?

[Winni]

Hi!


Ich hab in beiden Fällen auf die Schnelle ohne Optimierung gearbeitet, also

Code: Alles auswählen

tmpBitmap.canvas.pixel[x,y] := Color

bzw

Code: Alles auswählen

TmpBGRA.setPixel(x,y,Color);

Wenn ich jetzt mit Bitmap.scanline gegen BGRA.data optimiere wird es wahrscheinlich noch übler für die TBitmap.

Winni

[af0815]

Ich glaube keiner Statistik, die ich nicht selbst gefälscht habe

Wenn müsst man direktzugriff gegen direktzugriff testen. Das wäre Großteils mein Anwendungsfall. Generell ist es so, das BGRABitmap schon einige Berechnungen der Grauwerthelligkeit und anderes inkludiert hat.

[wp_xyz]

Hi!


Ich hab in beiden Fällen auf die Schnelle ohne Optimierung gearbeitet, also

Code: Alles auswählen

tmpBitmap.canvas.pixel[x,y] := Color

bzw

Code: Alles auswählen

TmpBGRA.setPixel(x,y,Color);

Wenn ich jetzt mit Bitmap.scanline gegen BGRA.data optimiere wird es wahrscheinlich noch übler für die TBitmap.

Kannst du deinen Code hier reinstellen? Ich bin zwar auch der Meinung, dass BGRABitmap schnell ist, aber gegen Canvas.Pixels[] zu vergleichen, ist wenig aussagekräftig und würde das Bitmap mit anderen Verfahren füllen.