24-Bit Bitmap um 90 grad drehen - Resourcen-Optimierung

[Harry Stahl]

Zitat von venice2:

Ich kenne solche Probleme nicht.
Liegt wohl daran das ich GDI+ verwende
GdipImageRotateFlip(img, Rotate90FlipNone);

Ist GDI+ denn wirklich schneller?

Hatte mal in der Vergangenheit ein zwei Sachen ausprobiert und war enttäuscht... Schließlich muss man ja immer erst diesen GDI-Kontext erzeugen und das Bild übergeben (was ja wohl auch einiges an Arbeitsspeicher braucht). Wie verhält sich GDI bei so großen Bildern (also die anfangs erwähnten 21600x10800)?

[striderx]

Zitat von Harry Stahl:

Ist GDI+ denn wirklich schneller?

Wie verhält sich GDI bei so großen Bildern (also die anfangs erwähnten 21600x10800)?

Schneller kann ich nicht sagen aber m. E. schon recht schnell. Allerdings gibt es für RotateFlip eine Größenbeschränkung. die irgendwo bei 65 Mio Pixel (bei einer 24 Bit-Bitmap) liegt; darüber ist kaum etwas im Netz zu finden. Nett ist auch, dass dann kein Fehler erzeugt wird und einfach nichts passiert.

Das kann man aber wie folgt umgehen:

Delphi-Quellcode:

function GDIPRotateFlipBitmap(ABitmap:  tBitmap;  Mode:  RotateFlipType):  Boolean;

var
  BM:         tBitmap;
  GR:         tGPGraphics;
  AGPBitmap:  tGPBitmap;
  AStatus:    Status;

begin
  if Mode = RotateNoneFlipNone then begin
     Result := True;
     Exit;
  end;
  
  BM := tBitmap.Create;                                                         
  BM.Assign(ABitmap);                                                           
  AGPBitmap := tGPBitmap.Create(BM.Handle, 0);                                  
  
  AGPBitmap.RotateFlip(Mode);
  GR := tGPGraphics.Create(ABitmap.Canvas.Handle);
  GR.DrawImage(AGPBitmap, 0, 0);
  AStatus := GR.GetLastStatus;
  
  Result := (AStatus = OK);
  
  AGPBitmap.Free;
  BM.Free;
  GR.Free;
end;

Wie sich das jetzt auf die Geschwindigtkeit auswirkt, muss Du dann mal ausprobieren.

[Harry Stahl]

Ich habe in meinem Programm eine Performance-Test Anzeige eingebaut (die man aktivieren muss) und habe Deine Funktion mal im Vergleich getestet:

Beide Funktionen sind in etwa gleich schnell. Wobei die GDI-Funktionen offensichtlich nur mit 32-Bit-Dateien funktionieren, hier muss ich also Datei erst in 32-Bit umwandeln, verbrauche dafür also schon mal mehr Arbeitsspeicher. Im Vergleich zu der 24-Bit-Drehung ist "meine" Funktion bei 660 Mio. Pixeln ca. 500 ms schneller (insgesamt hier auf dem PC ca. 6 Sekunden).

Aber man kann (zumindest mit der 64-Bit-Version) auch die 660 bzw. über 900 Mio. Pixel mit der GDI-Funktion benutzen, hier konnte ich keine Einschränkung feststellen.

Ich werde allerdings die Drehfunktion noch (wenn das geht) in eine Funktion mit Workerthreads umgestalten, wo jede CPU einen Teilbereich bearbeitet.

Das bringt echt noch mal Speed: Für die Funktion zur Änderung der Helligkeit habe ich das schon mal gemacht, während die Funktion für das oben erwähnte große Bild bei einer CPU z.B. 1,6 Sekunden braucht, um die Helligkeit zu ändern, geht es mit den Workerthreads (mit TTask) (ja nach Anzahl der CPUS) mit 6 CPUS z.B. in 300 MS. Das ist schon ein spürbarer Unterschied....

[striderx]

Zitat von Harry Stahl:

Wobei die GDI-Funktionen offensichtlich nur mit 32-Bit-Dateien funktionieren,

Wie kommst du denn darauf? Ich arbeite hier nur mit 24 Bit-Bitmaps und alle GDI+-Funktionen klappen damit.

[Harry Stahl]

Ich rufe Deine Funktion wie folgt auf:

GDIPRotateFlipBitmap (bm, Rotate90FlipY);

In der Anlage siehst Du als Screenshot die Ausgangssituation und jeweils die Bilder mit Deiner Funktion gedreht, wenn es ein 24-Bit Bild ist und einmal als 32-Bit Bild.

Bei dem 24-Bit-Bild wird ein falsches Ergebnis zurück geliefert...

[striderx]

Hallo Harry,

ich habe es gerade mehrfach ausprobiert - bei mir ist das Ergebnis immer einwandfrei.

Das muss also an etwas anderem liegen. Ggf. an der Stelle, wo du die Bitmap in das Image überträgst?

Mir fällt auch auf, dass das 32 bit-Bild größer ist als das Ursprungsbild und dass das 24 bit-Ergebnis einen zweiten, seitenverkehrten Kalenderblock enthält.


Alles Gute
Volker

[Harry Stahl]

Also das 32-Bit wirkt nur größer, da es schon (richtig) gedreht wurde.
Das 24-Bit wurde mit Deiner Funktion "gedreht", aber hat ersichtlich nicht funktioniert.

Ich mache gleich mal zum Testen ein neues Miniprojekt und teste das mal...

[himitsu]

Umwandeln in 32 Bit und dann damit arbeiten macht den Code natürlich einfacher. (kein Align und Dergleichen)
Und das Kopieren der Pixel düfte in 32 Bit auch schneller sein. (kopieren ganzer und vor allem ausgerichteter Integer).
Wenn man es am Ende 32 Bit lässt (erstpart das Rückumwandeln), dann müsste man mal sehn, ob das Umwandeln von 24->32 Bit das Zeitplus des optimierten/einfacherem Codes für 32 Bit nicht auffrisst.

Nja, du mußt für die Berechnungen halt immer den richtigen Zeilenanfang benutzen.
* man könnte ein Array mit den Anfängen aufbauen, jeweils aus .Scanline[]
* oder du nimmst die letzte Zeile und mußt aber für die Zeilenbreite den ausgerichteten/aufgerundeten Wert benutzen

Delphi-Quellcode:

//LineWidth := RoundUp(LineWidth / 4) * 4;
//LineWidth := Trunc(/LineWidth + 3) / 4) * 4;
LineWidth := (LineWidth + 3) and not 3;

Das ScanLine[] in der Schleife braucht es auch nicht, denn Quell- und Zielpixel lassen sich gleichermaßen direkt von der letzten Zeile aus berechnen.
Pos = (X * LineWidthInByte) + (Y * PixelSizeInByte)

Ein INC mit den typisierten Zeigern ist nicht so praktisch, wenn man da das Align einbeziehen muß (bei 24 Bit),
aber über einen Cast nach PByte ließe sich das Problem lösen.

Delphi-Quellcode:

Inc(PByte(Sourc), PixelSizeInByte);
Inc(PByte(Dest), LineWidthInByte);

Delphi-Quellcode:

// für 24 Bit
Last := Scanline[Height - 1];
for Y := Height - 1 downto 0 do begin
  Src := Last - (Y * (Width * 3) + 3) and not 3;  // oder Src := Last; vor die Y-Schleife und nach der X-Schleife ein Inc(PByte(Src), Die0bis3AlignBytes); bzw. Src auf den nächsten Integer aufrunden
  Dst := Last + Y * 3;
  for X := Width - 1 downto 0 do begin
    Dst^ := Src^;
    Inc(PByte(Src), 3);
    Dec(PByte(Dst), Width * 3);  // bzw. die Pointer als Byte-Typ mit Pointerarithmetik und dafür der Cast beim Kopieren -> PRGBTripple(Dst)^ := PRGBTripple(Src)^;
  end;
end;

// für 32 Bit (das Auskommentierte für Byte-Typen)
Last := Scanline[Height - 1];
for Y := Height - 1 downto 0 do begin
  Src := Last - Y * Width {* 4};  // oder Src := Last; vor die Y-Schleife ... die Zeilen liegen ja alle sowieso direkt hintereinander
  Dst := Last + Y {* 4};
  for X := Width - 1 downto 0 do begin
    Dst^ := Src^;
    Inc(Src {, 4});
    Dec(Dst, Width {* 4});  
  end;
end;

(falls ich mich nicht vertan hab)