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

[striderx]

Zitat:

Zitat von venice2 (Beitrag 1475730)

Ist zwar schnell aber das Ergebnis zu meiner Funktion ist nur schlecht.

Ich habe gerade Harrys Beispiel-Bild in vier 90-Grad-Schritten gedreht, und das Ergebnis ist identisch mit dem Ausgangsbild (Vergleich aller Pixel).

[Renate Schaaf]

Zitat:

Zu guter letzt noch die Feststellung, dass sich die WorkerThreads eigentlich nur bei ganz großen Dateien lohnen

Meine (erst kürzlich erworbene) Erfahrung sagt, dass es sich gar nicht lohnt. Ich hab einen Thread gemacht, der nur eine vertikale Scheibe der Bitmap rotiert. Nachdem ich endlich herausgefunden hatte, wie 2 solcher threads an den selben Bitmaps arbeiten können, ohne critical sections und ohne AV, musste ich feststellen, dass die langsamer sind. Bei einer 16000x16000 sogar doppelt so langsam. Vielleicht habe ich was falsch gemacht, aber auf alle Fälle mal wieder viel gelernt.

Gruß, Renate

[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.

Delphi-Quellcode:

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)

[Harry Stahl]

Zitat:

Zitat von striderx (Beitrag 1475717)

Nachtrag der Vollständigkeit halber :)

Delphi-Quellcode:

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

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

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);
  
  if (ABitmap.Width <> ABitmap.Height) and
>     (Mode in [Rotate90FlipNone, Rotate270FlipNone,
>               Rotate90FlipX, Rotate270FlipX,
>               Rotate90FlipY, Rotate270FlipY,
>               Rotate90FlipXY, Rotate270FlipXY]) then begin
     W := ABitmap.Width;
     ABitmap.Width  := ABitmap.Height;
     ABitmap.Height := W;
  end;
  
  GR := tGPGraphics.Create(ABitmap.Canvas.Handle);
  GR.DrawImage(AGPBitmap, 0, 0);
  AStatus := GR.GetLastStatus;
  
  Result := (AStatus = OK);
  
  AGPBitmap.Free;
  BM.Free;
  GR.Free;
end;

So funktioniert es zwar auch unter 24 Bit, das ist dann alles aber sehr langsam. Mich irritiert halt, dass die Drehung bei 32-Bit auch in Deiner ursprünglichen Fassung funktioniert.

Mit Deiner letzten Ergänzung dauert es ca. 9,3 Sekunden, um die große Welt-Grafik zu drehen (24-Bit Fassung), die 32-Bit-Fassung geht allerdings genau so schnell wie Deine alte Fassung...

[Harry Stahl]

Zitat:

Zitat von dummzeuch (Beitrag 1475713)

Zitat:

Zitat von Harry Stahl (Beitrag 1475697)

Ich habe ja die Original-Routine von Doberenz schon um ca. 20% Speed gesteigert, indem ich das

PEnd := Bm.scanline[bm.height-1];

vor die Schleife gesetzt habe und in der Schleife nur den gespeicherten Wert zuweisen muss. Aber "rowout := help.scanline [y];" brauche ich doch weiterhin und kann es nicht ersetzen.

Du kannst Die Adressen der Zeilen jeweils selbst berechnen. Das sind dann nur noch zwei Aufrufe von Scanline[]. Das macht einen riesigen Unterschied.

Ich habe darüber vor einiger Zeit mal geblogt.

Edit: Ich sehe gerade, Renate Schaaf hatte das auch schon geschrieben, incl. Code. Sorry für das Duplikat.

Danke, interessanter Artikel.

[Harry Stahl]

Zitat:

Zitat von Renate Schaaf (Beitrag 1475756)

Zitat:

Zu guter letzt noch die Feststellung, dass sich die WorkerThreads eigentlich nur bei ganz großen Dateien lohnen

Meine (erst kürzlich erworbene) Erfahrung sagt, dass es sich gar nicht lohnt. Ich hab einen Thread gemacht, der nur eine vertikale Scheibe der Bitmap rotiert. Nachdem ich endlich herausgefunden hatte, wie 2 solcher threads an den selben Bitmaps arbeiten können, ohne critical sections und ohne AV, musste ich feststellen, dass die langsamer sind. Bei einer 16000x16000 sogar doppelt so langsam. Vielleicht habe ich was falsch gemacht, aber auf alle Fälle mal wieder viel gelernt.

Gruß, Renate

Doch, es lohnt sich auf jeden Fall bei großen Grafiken, wie gesagt, hier auf meinem Entwicklungs-PC von ca. 6 Sekunden auf 3 Sekunden mit Workerthreads (alle anderen Varianten ca. 5-6 Sekunden, mal abgesehen von GDI unter 32 Bit).

Aber auch bei kleineren Grafiken gewinnt man speed, wenn bei kleinen Bildern (in der Höhe < 5000 Pixel) nur 2 CPUs verwendet werden, auch da ist die Worker-Thread Variante dann die schnellste Lösung (alle anderen Lösungen brauchen bei der kleineren Grafik so 130 -250 MS, die Worker-Thread-Varinate 80-130 MS). Bei mehr CPUs wird es
bei steigender Anzahl der verwendeten CPUS bei kleineren Grafiken immer langsamer, da ist dann der Verwaltungsaufwand zu groß).

[striderx]

Zitat:

Zitat von Harry Stahl (Beitrag 1475838)

So funktioniert es zwar auch unter 24 Bit, das ist dann alles aber sehr langsam. Mich irritiert halt, dass die Drehung bei 32-Bit auch in Deiner ursprünglichen Fassung funktioniert.

Mit Deiner letzten Ergänzung dauert es ca. 9,3 Sekunden, um die große Welt-Grafik zu drehen (24-Bit Fassung), die 32-Bit-Fassung geht allerdings genau so schnell wie Deine alte Fassung...

Da die ursprünglich Fassung die unterschiedlichen Werte für Höhe/Breite nicht berücksichtigt hat, dürfte das eigentlich nicht klappen, Sehr seltsam.

Ansonsten habe ich mir mal eine große Bitmap mit den von dir angegebenen Dimensionen erzeugt. Da bekomme ich ständig OutOfResources-Fehler.

Und was das Tempo anbelangt, so dürfte es doch zwischen alter und neuer Fassung keinen großen Unterschied geben - da ist doch nur die eine If-Abfrage dazugekommen (auch wenn Abfragen auf Mengen wohl nicht so schnell sind).


Und: Mich würde interessieren, wie du 24 in 32 bit umwandelst.

[Harry Stahl]

[QUOTE=striderx;1475851]

Zitat:

Zitat von Harry Stahl (Beitrag 1475838)

Und: Mich würde interessieren, wie du 24 in 32 bit umwandelst.

Da ist eigentlich nichts besonderes.

1. Ich setze bei der Bitmap das Pixelformat auf pf32bit;
2. Ich rufe eine eigene Funktion "SetVisibleRGBAMask" auf, die einfach nur alle Alpha-Werte auf 255, also sichtbar schaltet.
3. Dann setze ich Bitmap.Alphaformat auf afDefined

Warum fragst Du?

[striderx]

[QUOTE=Harry Stahl;1475912]

Zitat:

Zitat von striderx (Beitrag 1475851)

Zitat:

Zitat von Harry Stahl (Beitrag 1475838)

Und: Mich würde interessieren, wie du 24 in 32 bit umwandelst.

Da ist eigentlich nichts besonderes.

1. Ich setze bei der Bitmap das Pixelformat auf pf32bit;
2. Ich rufe eine eigene Funktion "SetVisibleRGBAMask" auf, die einfach nur alle Alpha-Werte auf 255, also sichtbar schaltet.
3. Dann setze ich Bitmap.Alphaformat auf afDefined

Warum fragst Du?

Wenn ich bei einer 24 bit-Bitmap das Pixelformat auf 32 bit setze, speichere, wieder lade und das Pixelformat dann abfrage, erhalte ich als Ergebnis wieder 24 bit. Die Datei-Eigenschaften unter Windows zeigen allerding schon 32 bit an. Seltsam.

[Harry Stahl]

[QUOTE=striderx;1475928]

Zitat:

Zitat von Harry Stahl (Beitrag 1475912)

Zitat:

Zitat von striderx (Beitrag 1475851)

Zitat:

Zitat von Harry Stahl (Beitrag 1475838)

Und: Mich würde interessieren, wie du 24 in 32 bit umwandelst.

Da ist eigentlich nichts besonderes.

1. Ich setze bei der Bitmap das Pixelformat auf pf32bit;
2. Ich rufe eine eigene Funktion "SetVisibleRGBAMask" auf, die einfach nur alle Alpha-Werte auf 255, also sichtbar schaltet.
3. Dann setze ich Bitmap.Alphaformat auf afDefined

Warum fragst Du?

Wenn ich bei einer 24 bit-Bitmap das Pixelformat auf 32 bit setze, speichere, wieder lade und das Pixelformat dann abfrage, erhalte ich als Ergebnis wieder 24 bit. Die Datei-Eigenschaften unter Windows zeigen allerding schon 32 bit an. Seltsam.

Kannst Du mal ein Code-Beispiel geben? Hier wird eine 32-Bit-Bitmap so gespeichert und nach dem Laden ist es auch wieder eine 32-Bit-Bitmap.