Geht das noch schneller? - Bitmap-Verrechnung

[Harry Stahl]

Danke, das war ein wichtiger Hinweis, den ich übersehen hatte: Wenn die Bitmap Premultiplied ist, funktioniert die Alphablend-Funktion auch wie bei allen Bitmaps wie gewünscht!!

Insgesamt ist dann die Kombination temporäres Premultiplied-Bitmap erzeugen und mit Alphablend benutzen schon schneller als die hier bislang gefundene Lösung.

Das hier ist meine aktuelle PreMultiply-Funktion:

Kann man das auch noch irgendwie beschleunigen?

Delphi-Quellcode:

procedure PreMultiply (bm: TBitmap); inline;
var
  y, x: Integer;
  RGBA: pRGBALine;
begin
  for y := 0 to bm.Height-1 do begin
    RGBA := bm.Scanline[y];
    for x := 0 to bm.Width-1 do begin
      if (RGBA^[x].rgbReserved <> 0) and (RGBA^[x].rgbReserved <> 255) then begin
        if RGBA^[x].rgbRed <> 0 then RGBA^[x].rgbRed := round ((RGBA^[x].rgbReserved * RGBA^[x].rgbRed ) / 255);
        if RGBA^[x].rgbGreen <> 0 then RGBA^[x].rgbGreen := round ((RGBA^[x].rgbReserved * RGBA^[x].rgbGreen ) / 255);
        if RGBA^[x].rgbBlue <> 0 then RGBA^[x].rgbBlue := round ((RGBA^[x].rgbReserved * RGBA^[x].rgbBlue ) / 255);
      end;
    end;
  end;
end;

[Dejan Vu]

Ja, kann man. Einfach die Beiträge durchlesen (Array vs. Pointer, Integer vs. FP mathematik (Stichwort: 'MulDiv')

Du kannst die Ergebnisse der Rechnung auch vorher einmal in einer Matrix vornehmen und dann nur noch auslesen. Dann hast Du einmalig overhead aber bei vielen Berechnungen könnte sich das lohnen, zumal Du wohl auf FP-Mathematik bestehst. Warum auch immer.

Delphi-Quellcode:

var
  lkup : Array [0..255, 0..255] of Byte;

Begin
  for i:=0 to 255 do for j:=0 to 255 do lkup[i,j] := round(i*j/255);
End;

...
for y := 0 to bm.Height-1 do begin
  RGBA := bm.Scanline[y];
  for x := 0 to bm.Width-1 do begin
    if (RGBA^.rgbReserved <> 0) and (RGBA^.rgbReserved <> 255) then begin
      if RGBA^.rgbRed <> 0 then RGBA^.rgbRed := lk[RGBA^.rgbReserved , RGBA^.rgbRed];
      if RGBA^.rgbGreen <> 0 then RGBA^.rgbGreen := lk[RGBA^.rgbReserved, RGBA^.rgbGreen];
      if RGBA^.rgbBlue <> 0 then RGBA^.rgbBlue := lk[RGBA^.rgbReserved, RGBA^.rgbBlue];
    end;
   inc(RGBA);
  end;
end;

[BUG]

Die inneren Verzweigungen wegzulassen könnte auch noch was bringen:

Delphi-Quellcode:

var
  lkup : Array [0..255, 0..255] of Byte;

Begin
  for i:=0 to 255 do for j:=0 to 255 do
  begin
    if (j <> 0) and (j <> 255) then // ist j <> 0 überhaupt korrekt hier?
      lkup[i,j] := round(i*j/255)
    else
      lkup[i,j] := j;
  end;
End;

...
for y := 0 to bm.Height-1 do begin
  RGBA := bm.Scanline[y];
  for x := 0 to bm.Width-1 do begin
    RGBA^.rgbRed := lk[RGBA^.rgbReserved , RGBA^.rgbRed];
    RGBA^.rgbGreen := lk[RGBA^.rgbReserved, RGBA^.rgbGreen];
    RGBA^.rgbBlue := lk[RGBA^.rgbReserved, RGBA^.rgbBlue];
   inc(RGBA);
  end;
end;

[Harry Stahl]

Das hatte ich gerade auch zufälligerweise im Internet gefunden.

Doch Überraschung: Ist deutlich langsamer, als meine Funktion, die ich gepostet hatte. Wahrscheinlich kostet der doppelte Zugriff auf das byte-Array mehr Zeit als die direkte Berechnung der Werte.

Edit: Halt, diese Aussage muss ich evtl. zurückziehen. Wenn ich folgende logische Abfrage wie bei mir oben einbaue, ist es zumindest ähnlich schnell:

  if RGBA^[x].rgbReserved <> 255 then begin Hängt dann eben davon ab, wieviel Pixel überhaupt Transparent sind, denn nur die müssen ja berechnet werden, die anderen können den Wert behalten.

[Dejan Vu]

Das Lookup-Array wird nur einmal berechnet, da ist es unerheblich, etwas zu optimieren. Daher würde ich diesen Vorgang nicht in die Performancebetrachtungen mit einbeziehen.
Beim Schreiben des Vorschlags ist mir aber auch aufgefallen, das es bei drei Operationen (*, /, round) nicht allzuviel zu optimieren gibt.
Aber wieso verwendest Du 'MulDiv' nicht? Das Ergebnis ist um höchstens 1 unterschiedlich (Rundungsverhalten).

[Mavarik]

Zitat von Dejan Vu:

Aber wieso verwendest Du 'MulDiv' nicht?

MulDiv ist immer ein Far-Call und Jumps und damit auf jeden Fall langsamer. (Auch wenn ich es nicht getestet habe)

Aber ein

C := A * 5 div B;

ist:

Code:

xor eax,eax
mov al,[ebp-$5]
lea eax,[eax+eax*4]
xor edx,edx
mov dl,[ebp-$06]
mov ecx,edx
xor edx,edx
div ecx
mov edx,[ebp-$04]
mov [edx+$002d4],al

ein C := MULDIV(A,5,B) ist:

Code:

xor eax,eax
mov al,[ebp-$6]       
push eax
push $05
xor eax,eax
mov al,[ebp-$5)
Push eax             // bishier schon fast so viele Ticks wie oben
CALL MulDiv
// aus MulDiv
jmp dword ptr[$00896ae8]
mov eax,[esp+$04}
or eax,eax
js $75201b80
mov edx,[esp+$80]
or edx,edx
js $75201c06
mul edx
mov ecx,[eps+$0c]
or ecx,ecx
js $75201c48
sar ecx,1
add eax,ecx
adc edx.$00
cmp edx,[esp+$0c]
jnb $75201b7a
div dword ptr [esp+$0c]
or eax,eay
js $75201b7a
ret $000c
mov edx,[ebp-$04]   // gleich mit oben
mov [edx+$02d4],al  // gleich mit oben

Ein C := A * B div 8 ist:

Code:

xor eax,eax         // gleich mit oben 
mov al,[ebp-$05]    // gleich mit oben
xor edx,edx         // gleich mit oben
mov dl,[ebp-$06],
imul edx
shr eax, $03        // div 8 erkannt
mov edx,[ebp-$04]   // gleich mit oben
mov [edx+$02d4],al  // gleich mit oben

Mavarik

[Dejan Vu]

MulDiv basiert auf In64 und ist damit überlauf-sicher, was bei A*B div C imho nicht der Fall ist. Dafür ist es langsamer als der das einfache A*B DIV C.

Bezüglich des Performancevergleiches zielte ich eher auf 'MulDiv' vs. 'Round(A*B/C)' ab, also Floating Point Arithmetik.

[Harry Stahl]

Zitat von Dejan Vu:

Aber wieso verwendest Du 'MulDiv' nicht? Das Ergebnis ist um höchstens 1 unterschiedlich (Rundungsverhalten).

Das habe ich schon in Betrag Nr. 10 gesagt, weil es dann doppelt so lange braucht.

[Harry Stahl]

Um die bisherigen Ergebnisse zusammenzufassen:

* Zugriff auf ein Lookup-Array dauert länger, als die Berechnung.
* MulDiv bringt eindeutig keine Beschleunigung
* Im vorliegenden Fall bringt auch eine Parallelisierung nichts, da der Verwaltungsaufwand
größer ist, als der Gewinn durch mehrere Prozessorkerne

Das bislang schnellste Ergebnis liefert der untenstehende Code, egal, ob per Pointer-Addition oder Array-Zugriff:

Delphi-Quellcode:

procedure Draw32BitToBitmapxxx(const BitOben: TBitmap; BitUnten: TBitmap); // Array-Zugriff
var
   h,w,i, r, g, b: Integer;
   RGBA_Unten, RGBA_Oben: pRGBALine;
begin
    for h := 0 to BitUnten.Height-1 do begin
     RGBA_Unten := BitUnten.ScanLine[h];
     RGBA_Oben := BitOben.ScanLine[h];

     For w:= 0 to BitUnten.Width-1 do begin
       if RGBA_Oben^[w].rgbReserved = 0 then begin
         // unten bleibt
       end else begin
         RGBA_Unten^[w].rgbred := (RGBA_Oben^[w].rgbReserved * (RGBA_Oben^[w].rgbred - RGBA_Unten^[w].rgbred) shr 8 + RGBA_Unten^[w].rgbred);
         RGBA_Unten^[w].rgbGreen := (RGBA_Oben^[w].rgbReserved * (RGBA_Oben^[w].rgbgreen - RGBA_Unten^[w].rgbGreen) shr 8 + RGBA_Unten^[w].rgbGreen);
         RGBA_Unten^[w].rgbBlue := (RGBA_Oben^[w].rgbReserved * (RGBA_Oben^[w].rgbBlue - RGBA_Unten^[w].rgbBlue) shr 8 + RGBA_Unten^[w].rgbBlue);

         RGBA_Unten^[w].rgbReserved := 255;
       end;
    end;
   end;
end;

procedure Draw32BitToBitmapnew(const BitOben: TBitmap; BitUnten: TBitmap); // Pointer-Addition
var
  h,w: Integer;
  RGBA_Unten, RGBA_Oben: ^TRGBQuad; // pRGBALine;
begin
  For h := 0 to BitUnten.Height-1 do begin
    RGBA_Unten := BitUnten.ScanLine[h];
    RGBA_Oben := BitOben.ScanLine[h];

    For w:= 0 to BitUnten.Width-1 do begin
      if RGBA_Oben^.rgbReserved = 0 then begin
        // unten bleibt
      end else begin
        RGBA_Unten^.rgbBlue  := ((RGBA_Oben^.rgbReserved * (RGBA_Oben^.rgbBlue -  RGBA_Unten^.rgbBlue))  shr 8 + RGBA_Unten^.rgbBlue);
        RGBA_Unten^.rgbGreen := ((RGBA_Oben^.rgbReserved * (RGBA_Oben^.rgbgreen - RGBA_Unten^.rgbGreen)) shr 8 + RGBA_Unten^.rgbGreen);
        RGBA_Unten^.rgbred   := ((RGBA_Oben^.rgbReserved * (RGBA_Oben^.rgbred -   RGBA_Unten^.rgbred))   shr 8 + RGBA_Unten^.rgbred);

        RGBA_Unten^.rgbReserved := 255;
      end;
      inc (RGBA_Unten);
      inc (RGBA_oben);
   end;
  end;
end;

[Mavarik]

Zitat von Harry Stahl:

* Im vorliegenden Fall bringt auch eine Parallelisierung nichts, da der Verwaltungsaufwand
größer ist, als der Gewinn durch mehrere Prozessorkerne

Das kann ich eigentlich kaum glauben.

Vielleicht über die Parallel FOR ok, kann ich nicht nachvollziehen. Aber einen optimierten thread mit entsprechendem vorbereiteten Prozessen müsste schneller sein.

Können wir am Sa. ja mit unserem Thread König, emm Kaiser, ich meine Kaisler diskutieren.

Mavarik