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

[striderx]

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;

[haentschman]

Zitat:

der Vollständigkeit halber

Vollständig wäre es mit try/finally Blocks...

[Jens01]

Wenn ich das eben richtig nachgelesen habe, kann man für Bitmap-Veränderungen auch die Intel-Prozessoren direkt ansteuern, was der Bearbeitung noch mal Schub verleihen soll.
Intel Integrated Performance Primitives for Intel Architecture
Hier ist ein Header.
Ich weiß nur nicht genau, wie man den Header ansteuert.

[striderx]

Zitat von haentschman:

Zitat:

der Vollständigkeit halber

Vollständig wäre es mit try/finally Blocks...

Grundsätzlich richtig, aber an welcher Stelle meinst du denn, dass hier eine Exception 'durchschlägt'?. Seitens GDI+ m. W. nicht, da kann man nur mit GetLastStatus den Status der letzten Operation abfragen. Könnte man natürlich verschachteln mit mehreren if AStatus = OK , aber bei dem Größenbug von FlipRotate ist der Status OK. Und selbst wenn man das tBitmap.Create wegläßt, knallt es nicht.

Aber vielleicht übersehe ich ja etwas.

[venice2]

Zitat von striderx:

Zitat von haentschman:

Zitat:

der Vollständigkeit halber

Vollständig wäre es mit try/finally Blocks...

Grundsätzlich richtig, aber an welcher Stelle meinst du denn, dass hier eine Exception 'durchschlägt'?. Seitens GDI+ m. W. nicht, da kann man nur mit GetLastStatus den Status der letzten Operation abfragen. Könnte man natürlich verschachteln mit mehreren if AStatus = OK , aber bei dem Größenbug von FlipRotate ist der Status OK. Und selbst wenn man das tBitmap.Create wegläßt, knallt es nicht.

Aber vielleicht übersehe ich ja etwas.

Alles gut und schön.
Nur die Funktion im GDITest Projekt spiegelt das Bild es wird nicht korrekt dargestellt.
GDIPRotateFlipBitmap (bm, Rotate90FlipY);

GDIPRotateFlipBitmap (bm, Rotate90FlipNone);
wäre korrekt!
Ist zwar schnell aber das Ergebnis zu meiner Funktion ist nur schlecht.
Vergleiche beide Bilder das von mir hochgeladene und das hier.
Das vergleichen kann man hier vergessen da die Konvertierung des Bitmap (*.png) zu *.jpg (Hier im Forum) das original verfälscht.

[striderx]

Zitat von venice2:

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

[Harry Stahl]

Zitat von 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

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ß).

[Harry Stahl]

Zitat von striderx:

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

[striderx]

Zitat von Harry Stahl:

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.