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

[Harry Stahl]

Das Thema hatten wir hier zwar schon öfter, aber nicht unter dem Gesichtspunkt, den ich hier ansprechen möchte:

Ich nutze zum drehen von 24 bzw. 32 Bitmaps bislang immer die folgende Routine (aus dem Doberenz-Buch):

Delphi-Quellcode:

procedure Drehe90Rechts (bm: TBitmap);
type
  TMyHelp = array [0..0] of TRGBQuad;
var
  P, Pend : PRGBQuad; x, y, b, h: Integer;  RowOut: ^TMyHelp;  help: TBitmap;
begin
  Bm.pixelformat := pf32bit;

  help := TBitmap.create;
  help.pixelformat := pf32bit;

  b := bm.height;
  h := bm.width;

  help.SetSize (b, h);
  PEnd := Bm.scanline[bm.height-1];

  for y := 0 to h-1 do begin

    rowout := help.scanline [y];
    p := PEnd;
    inc (p, y);

    for x := 0 to (b-1) do begin
      rowout [x] := p^;
      inc (p, h);
    end;

  end;

  bm.Assign (help);
  help.free;
end;

Ich dachte, OK die nehmen auch für eine 24-Bit-Bitmap eine 32-Bitmap, weil der Compiler die 32-Bits in einem Register direkt kopieren kann. Wenn man sich das in der CPU ansieht, dann stimmt das wohl auch, bei 24 muss er wohl erst 16-Bit und dann noch mal 8 kopieren, dadurch 2 Befehle mehr (siehe anliegenden Screenshot).

Nur: Bei sehr großen Bilder (teste gerade eins im Format 21600 x 10800) braucht er, aber um die 32-Bit-Hilfsbit anzulegen, statt 660 MB bei einer 24 Bit, bei der 32-Bit Bitmap ca. 1 GB zusätzlichen Arbeitsspeicher.

Daher meine Überlegung, statt die Routine mit 32-Bit zu verwenden, bei einer 24-Bit es mit einer 24-Bit routine zu machen.

Delphi-Quellcode:

procedure Drehe90Rechts24 (bm: TBitmap);
type
  TMyHelp = array [0..0] of TRGBTriple;
var
  P, Pend : PRGBTriple; x, y, b, h: Integer;  RowOut: ^TMyHelp;  help: TBitmap;
begin
  help := TBitmap.create;
  help.pixelformat := pf24bit;

  b := bm.height;
  h := bm.width;

  help.SetSize (b, h);
  PEnd := Bm.scanline[bm.height-1];

  for y := 0 to h-1 do begin

    rowout := help.scanline [y];
    p := PEnd;
    inc (p, y);

    for x := 0 to b-1 do begin
      rowout [x] := p^;
      inc (p, h);
    end;

  end;

  bm.Assign (help);
  help.free;
end;

Leider funktioniert die nicht. Komme leider nicht dahinter warum (es fehlen 1-2 Pixel) und bei Bildgrößen mit ungeraden werten geht es nach dem 2. Drehen ganz schief.

Hat einer eine Idee, wie man es richtig machen könnte?

[Gausi]

Vor Ewigkeiten habe ich Bitmaps mal per Hand geparsed und verarbeitet, und bin dabei auf die Eigenart gestoßen, dass jede Zeile in einer Bitmap-Datei ein Vielfaches von 4 Bytes enthalten muss. Bei 32 Bit ist das automatisch der Fall, bei 24Bit hat man ggf. bis zu 3 Füllbytes am Ende jeder Zeile.

Könnte das die Ursache deines Problems sein?

[Harry Stahl]

Da hatte ich auch schon dran gedacht, aber keine Idee, wie ich das im Code berücksichtigen sollte...

[Harry Stahl]

Habe das mit den Füllbytes noch mal aufgegriffen und mache die Höhe oder Breite passend.

Von einem Test-Bitmap mit Breite = 2348 und Höhe= 3181 wird dann aus der Höhe 3184. Wenn ich nun die Bytes des alten Bitmaps in die vergrößerte Bitmap kopiere, wird alles kopiert und ich kann das Bitmap danach auch weiter drehen.

Allerdings: Ich habe eine um 3 Pixel vergrößerte Bitmap. Wenn ich die dann wieder kürze, gibt es aber beim nächsten Mal drehen ein Problem mit der Anzeige.

Wie macht man das wohl richtig?

Delphi-Quellcode:

procedure Drehe90Rechts24 (bm: TBitmap);
type
  TMyHelp = array [0..0] of TRGBTriple;
var
  P, Pend : PRGBTriple; x, y, b, h, oldw, oldh: Integer;  RowOut: ^TMyHelp;  help: TBitmap;
begin
  help := TBitmap.create;
  help.pixelformat := pf24bit;

  oldw := bm.Width;
  oldh := bm.Height;

  b := bm.height;
  h := bm.width;

  if bm.Width mod 4 <> 0 then
     h := ((bm.Width div 4) * 4) + 4;
   if bm.Height mod 4 <> 0 then
     b := ((bm.Height div 4) * 4) + 4;

  help.SetSize (b, h);
  PEnd := Bm.scanline[bm.height-1];

  for y := 0 to bm.width-1 do begin

    rowout := help.scanline [y];
    p := PEnd;
    inc (p, y);

    for x := 0 to bm.height-1 do begin
      rowout [x] := p^;
      inc (p, bm.Width);
    end;

  end;

  bm.Assign (help);
  //bm.SetSize(oldh, oldw);
  //BitBlt(bm.canvas.handle, 0,0, bm.Width, bm.Height, help.canvas.handle, 0,0, SRCCopy); // funktioniert nur beim 1. drehen
  help.free;
end;

[venice2]

Ich kenne solche Probleme nicht.
Liegt wohl daran das ich GDI+ verwende

Delphi-Quellcode:

GdipImageRotateFlip(img, Rotate90FlipNone);

[Amateurprofi]

Zitat:

Zitat von Harry Stahl (Beitrag 1475674)

Das Thema hatten wir hier zwar schon öfter, aber nicht unter dem Gesichtspunkt, den ich hier ansprechen möchte:

Ich nutze zum drehen von 24 bzw. 32 Bitmaps bislang immer die folgende Routine (aus dem Doberenz-Buch):

Delphi-Quellcode:

procedure Drehe90Rechts (bm: TBitmap);
type
  TMyHelp = array [0..0] of TRGBQuad;
var
  P, Pend : PRGBQuad; x, y, b, h: Integer;  RowOut: ^TMyHelp;  help: TBitmap;
begin
  Bm.pixelformat := pf32bit;

  help := TBitmap.create;
  help.pixelformat := pf32bit;

  b := bm.height;
  h := bm.width;

  help.SetSize (b, h);
  PEnd := Bm.scanline[bm.height-1];

  for y := 0 to h-1 do begin

    rowout := help.scanline [y];
    p := PEnd;
    inc (p, y);

    for x := 0 to (b-1) do begin
      rowout [x] := p^;
      inc (p, h);
    end;

  end;

  bm.Assign (help);
  help.free;
end;

Ich dachte, OK die nehmen auch für eine 24-Bit-Bitmap eine 32-Bitmap, weil der Compiler die 32-Bits in einem Register direkt kopieren kann. Wenn man sich das in der CPU ansieht, dann stimmt das wohl auch, bei 24 muss er wohl erst 16-Bit und dann noch mal 8 kopieren, dadurch 2 Befehle mehr (siehe anliegenden Screenshot).

Nur: Bei sehr großen Bilder (teste gerade eins im Format 21600 x 10800) braucht er, aber um die 32-Bit-Hilfsbit anzulegen, statt 660 MB bei einer 24 Bit, bei der 32-Bit Bitmap ca. 1 GB zusätzlichen Arbeitsspeicher.

Daher meine Überlegung, statt die Routine mit 32-Bit zu verwenden, bei einer 24-Bit es mit einer 24-Bit routine zu machen.

Delphi-Quellcode:

procedure Drehe90Rechts24 (bm: TBitmap);
type
  TMyHelp = array [0..0] of TRGBTriple;
var
  P, Pend : PRGBTriple; x, y, b, h: Integer;  RowOut: ^TMyHelp;  help: TBitmap;
begin
  help := TBitmap.create;
  help.pixelformat := pf24bit;

  b := bm.height;
  h := bm.width;

  help.SetSize (b, h);
  PEnd := Bm.scanline[bm.height-1];

  for y := 0 to h-1 do begin

    rowout := help.scanline [y];
    p := PEnd;
    inc (p, y);

    for x := 0 to b-1 do begin
      rowout [x] := p^;
      inc (p, h);
    end;

  end;

  bm.Assign (help);
  help.free;
end;

Leider funktioniert die nicht. Komme leider nicht dahinter warum (es fehlen 1-2 Pixel) und bei Bildgrößen mit ungeraden werten geht es nach dem 2. Drehen ganz schief.

Hat einer eine Idee, wie man es richtig machen könnte?

Zu Drehe90Rechts24 (bm: TBitmap);


Vor der ersten Schleife wird PEnd auf das erste Pixel der letzten Zeile in BM gestellt
In der Y Schleife wird
1) P = PEnd gesetzt, also auf Pixel[0,letzte Zeile]
2) P um Y erhöht, also auf Pixel[Y,letzte Zeile gestellt]
In der X Schleife wird
1) Pixel P^ nach Help kopiert
2) P um H Pixel erhöht.
Das soll P auf die jeweils nächste Zeile in BM stellen.
Das funktioniert bei 32 Bit-Bitmaps, aber nicht bei 24 Bit, weil hier
der Offset zur nächsten Zeile (in Bytes) nicht Breite*3 ist, sondern immer ein
vielfaches von 4 ist. (Breite*3+3) div 4*4 sollte die Anzahl Bytes je Zeile ergeben.
Workaround:
var Offs:NativeInt;
1) Vor der Y Schleife
PEnd := Bm.scanline[bm.height-1];
Offs := NativeInt(Bm.scanline[bm.height-2])-NativeInt(PEnd);
2) In der X Schleife
Inc (NativeInt(p), Offs); // statt inc (p, h);

[Harry Stahl]

Danke, Du hast mir den Tag gerettet :thumb:, da knabber ich schon ein paar Stunden dran rum...

Super, so braucht die Drehung "nur" zusätzlichen Arbeitsspeicher von 699 MB, statt 933 MB.
Erstaunlicherweise ist der Vorgang auch etwas schneller, als mit der 32-Bit-Variante (gemessen in der 64-Bit-Programm-Variante meines Programms). Wird wahrscheinlich durch die krass hohe Anzahl der Bytes, die weniger kopiert werden müssen (ca. 300 Mio) bewirkt...

[Harry Stahl]

Zitat:

Zitat von venice2 (Beitrag 1475680)

Ich kenne solche Probleme nicht.
Liegt wohl daran das ich GDI+ verwende

Delphi-Quellcode:

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:

Zitat von Harry Stahl (Beitrag 1475683)

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:

Zitat von Harry Stahl (Beitrag 1475686)

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

[Renate Schaaf]

Danke für die Idee mit den worker-threads, probier ich doch gleich mal aus!

Wenn man nur 2mal GetScanline aufruft, geht es auch schneller.

Renate

[Harry Stahl]

[Nicht] Anliegend ein Testprojekt, es funktioniert weder unter Delphi XE7 (was ich derzeit noch für das Programm verwende), noch unter dem aktuellsten 10.4.1...

Wegen der Dateigröße von 14 MB (das 24-bit-Bild) musste ich das Demo kurz auf meine eigene Seite laden, lasse es solange drauf, bis Du entweder sagst, Du willst es Dir nicht ansehen oder dass Du es geladen hast:

https://www.hastasoft.de/GDITest.zip

[Harry Stahl]

Zitat:

Zitat von Renate Schaaf (Beitrag 1475695)

Danke für die Idee mit den worker-threads, probier ich doch gleich mal aus!

Wenn man nur 2mal GetScanline aufruft, geht es auch schneller.

Renate

Gerne. Was meinst Du mit nur 2 mal aufrufen?

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.

Oder?

[Amateurprofi]

@Harry:

Wenn du auf Performance aus bist, dann versuch doch mal folgendes.
Sollte deutlich schneller sein.

Achtung:
Der 64Bit-Teil in CopyColumn24 ist ungetestet, weil das Projekt mit dem ich gerade herumspiele nicht 64Bit-fähig ist.
Unter 32 Bit (mit relativ kleinen Bitmaps) ergibt meine Messung dass das doppelt so schnell läuft, wie die ursprüngliche Routine.

Delphi-Quellcode:

PROCEDURE CopyColumn24(PSource,PDest:Pointer; Count,LO:NativeInt);
asm
{$IFDEF CPUX86}// RAX=PSource, RDX=PDest, RCX=Count, Stack=LO
               push     ebx
               mov      ebp,LO
               dec      ecx
@Loop:         mov      ebx,[eax]
               mov      [edx],ebx
               add      eax,ebp
               add      edx,3
               sub      ecx,1
               jnz      @Loop
               mov      bx,[eax]
               mov      [edx],bx
               mov      bl,[eax+2]
               mov      [edx+2],bl
               pop      ebx
{$ELSE}        // RCX=PSource, RDX=PDest, R8=Count, R9=LO
               dec      r8
@Loop:         mov      eax,[rcx]
               mov      [rdx],eax
               add      rcx,r9
               add      rdx,3
               sub      r8,1
               jnz      @Loop
               mov      ax,[rcx]
               mov      [rdx],ax
               mov      al,[rcx+2]
               mov      [rdx+2],al
{$ENDIF}
end;

Delphi-Quellcode:

PROCEDURE RotateRight24(Bmp:TBitmap);
var W,H,Y,LoSource,LoDest:NativeInt; PSource,PDest:PByte; Dest:TBitmap;
begin
   W:=Bmp.Height;
   H:=Bmp.Width;
   PSource:=Bmp.ScanLine[W-1];
   LoSource:=NativeInt(Bmp.ScanLine[W-2])-NativeInt(PSource);
   Dest:=TBitmap.Create;
   Dest.PixelFormat:=pf24bit;
   Dest.SetSize(W,H);
   PDest:=Dest.ScanLine[0];
   LoDest:=NativeInt(Dest.ScanLine[1])-NativeInt(PDest);
   for Y:=H-1 downto 0 do begin
      CopyColumn24(PSource,PDest,W,LoSource);
      Inc(PSource,3);
      Inc(PDest,LoDest);
   end;
   Bmp.Assign(Dest);
   Dest.free;
end;

[Renate Schaaf]

Zitat:

Gerne. Was meinst Du mit nur 2 mal aufrufen?

So in etwa:

Delphi-Quellcode:

procedure Drehe90Rechts24NurPointers(bm: TBitmap);
var
  P, Pend, Pdest: PRGBTriple;
  x, y, b, h: Integer;
  RowOut: PByte;
  help: TBitmap;
var
  Offs, OffsDest: NativeInt;
begin
  help := TBitmap.create;
  help.pixelformat := pf24bit;

  b := bm.height;
  h := bm.width;

  help.SetSize(b, h);
  RowOut := help.scanline[0];
  Pend := bm.scanline[bm.height - 1];
  Offs := ((h * 24 + 31) and not 31) div 8;
  OffsDest := ((b * 24 + 31) and not 31) div 8;
  for y := 0 to h - 1 do
  begin
    P := Pend;
    inc(P, y);
    Pdest := PRGBTriple(RowOut);
    for x := 0 to b - 1 do
    begin
      Pdest^ := P^;
      inc(Pdest);
      inc(NativeInt(P), Offs);
    end;
    dec(RowOut, OffsDest);
  end;

  bm.Assign(help);
  help.free;
 end;

[Harry Stahl]

Nur Pointer bringt auch noch mal 500 ms. Hier auf dem Entwicklungs-PC in der virtuellen Maschine wird das große Bild mit Deiner Variante in ca. 5 bis 5,5 Sek. gedreht.

Mit meiner ursprünglichen Variante und den Workerthreads geht's in ca. 3 Sekunden (auf meinem Vertriebs-PC (I5-Prozessor) geht's in ca. 1 Sekunde).

Im Vergleich zu MS-Paint: das braucht auf den Entwicklungs-PC 20 Sekunden um das Bild zu drehen, auf dem Vertreibs-PC 8 Sekunden (und verbraucht nach 1 mal Drehen 4.5 GB Arbeitsspeicher, mein Programm mit Undo-Aktiv ca. 2 GB).

[Harry Stahl]

Zitat:

Zitat von Amateurprofi (Beitrag 1475699)

@Harry:

Wenn du auf Performance aus bist, dann versuch doch mal folgendes.
Sollte deutlich schneller sein.

Achtung:
Der 64Bit-Teil in CopyColumn24 ist ungetestet, weil das Projekt mit dem ich gerade herumspiele nicht 64Bit-fähig ist.
Unter 32 Bit (mit relativ kleinen Bitmaps) ergibt meine Messung dass das doppelt so schnell läuft, wie die ursprüngliche Routine.

Delphi-Quellcode:

PROCEDURE CopyColumn24(PSource,PDest:Pointer; Count,LO:NativeInt);
asm
{$IFDEF CPUX86}// RAX=PSource, RDX=PDest, RCX=Count, Stack=LO
               push     ebx
               mov      ebp,LO
               dec      ecx
@Loop:         mov      ebx,[eax]
               mov      [edx],ebx
               add      eax,ebp
               add      edx,3
               sub      ecx,1
               jnz      @Loop
               mov      bx,[eax]
               mov      [edx],bx
               mov      bl,[eax+2]
               mov      [edx+2],bl
               pop      ebx
{$ELSE}        // RCX=PSource, RDX=PDest, R8=Count, R9=LO
               dec      r8
@Loop:         mov      eax,[rcx]
               mov      [rdx],eax
               add      rcx,r9
               add      rdx,3
               sub      r8,1
               jnz      @Loop
               mov      ax,[rcx]
               mov      [rdx],ax
               mov      al,[rcx+2]
               mov      [rdx+2],al
{$ENDIF}
end;

Delphi-Quellcode:

PROCEDURE RotateRight24(Bmp:TBitmap);
var W,H,Y,LoSource,LoDest:NativeInt; PSource,PDest:PByte; Dest:TBitmap;
begin
   W:=Bmp.Height;
   H:=Bmp.Width;
   PSource:=Bmp.ScanLine[W-1];
   LoSource:=NativeInt(Bmp.ScanLine[W-2])-NativeInt(PSource);
   Dest:=TBitmap.Create;
   Dest.PixelFormat:=pf24bit;
   Dest.SetSize(W,H);
   PDest:=Dest.ScanLine[0];
   LoDest:=NativeInt(Dest.ScanLine[1])-NativeInt(PDest);
   for Y:=H-1 downto 0 do begin
      CopyColumn24(PSource,PDest,W,LoSource);
      Inc(PSource,3);
      Inc(PDest,LoDest);
   end;
   Bmp.Assign(Dest);
   Dest.free;
end;

Oh, habe ich gerade erst gesehen (manchmal überholen sich die Beiträge irgendwie), werde ich mir morgen Abend auf jeden Fall auch noch mal ansehen und mich melden.

[Harry Stahl]

Zu guter letzt noch die Feststellung, dass sich die WorkerThreads eigentlich nur bei ganz großen Dateien lohnen. Bei kleineren Bitmaps (alles so unter 4000 x 4000) ist der Thread-Verwaltungsaufwand wohl zu hoch, da ist das z.T. auch schon mal langsamer als nur eine Routine. Da man auf alle Worker-Threads warten muss, bevor man das Ergebnis zuweist, kann es sich evtl. auch etwas in die Länge ziehen, wenn eine CPU zu sehr belastet ist und daher einen Thread etwas blockiert..

Vielleicht sollte ich auch nicht alle zur Verfügung stehenden CPUs nutzen, sondern immer 1 oder 2 weniger, damit so evtl. die restlichen voll für meine Berechnungsaufgaben zur Verfügung stehen.

Muss ich morgen noch mal testen...

[striderx]

Zitat:

Zitat von Harry Stahl (Beitrag 1475696)

[Nicht] Anliegend ein Testprojekt, es funktioniert weder unter Delphi XE7 (was ich derzeit noch für das Programm verwende), noch unter dem aktuellsten 10.4.1...

Wegen der Dateigröße von 14 MB (das 24-bit-Bild) musste ich das Demo kurz auf meine eigene Seite laden, lasse es solange drauf, bis Du entweder sagst, Du willst es Dir nicht ansehen oder dass Du es geladen hast:

https://www.hastasoft.de/GDITest.zip

Da ich hier immer mit quadratischen Bildern arbeite, ist mir das bislang nicht aufgefallen: Man muss bei nicht quadratischen Vorlagen natürlich auch die Dimensionen der Ziel-Bitmap entsprechend anpassen.

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

Viel Spaß beim weiteren Basteln.

[venice2]

Zitat:

Viel Spaß beim weiteren Basteln.

Dito!

Delphi-Quellcode:

procedure TForm34.Button1Click(Sender: TObject);
var
  bm: Tbitmap;
  Start, Stop: Cardinal;
begin
  Start := GetTickCount;
  bm := TBitmap.Create;
  bm.Assign(image1.Picture.Bitmap);
//  GDIPRotateFlipBitmap (bm, Rotate90FlipY);
  bm := FastAARotatedBitmap(bm.Handle, 90.0, TColor($FFFF),
    true, true, false, 1.0);
  Image2.Picture.Bitmap.Assign(bm);
  Image2.Refresh;
  Stop := GetTickCount - Start;
  Caption := Format('%d ms', [Stop]); // 656 ms ..
end;

[dummzeuch]

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.

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

:zwinker:

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

[striderx]

Zitat:

Zitat von haentschman (Beitrag 1475718)

Zitat:

der Vollständigkeit halber

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

:zwinker:

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

Delphi-Quellcode:

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:

Zitat von striderx (Beitrag 1475725)

Zitat:

Zitat von haentschman (Beitrag 1475718)

Zitat:

der Vollständigkeit halber

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

:zwinker:

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

Delphi-Quellcode:

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.

Delphi-Quellcode:

GDIPRotateFlipBitmap (bm, Rotate90FlipY);

Delphi-Quellcode:

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:

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.