Geht das noch schneller? - Bitmap-Verrechnung

[mensch72]

Sorry, der "Sicherheits-Cast" muss Integer(...) und nicht int(xxx) heißen!

also
i := RGBA_Unten^[w].rgbBlue - (((Integer(RGBA_Unten^[w].rgbBlue - RGBA_Oben^[w].rgbBlue) * Integer(RGBA_Oben^[w].rgbReserved)) div 256);
und
i := RGBA_Unten^[w].rgbBlue - (((Integer(RGBA_Unten^[w].rgbBlue - RGBA_Oben^[w].rgbBlue) * Integer(RGBA_Oben^[w].rgbReserved)) shr 8);

(ich sollte nicht so viel C++ programmieren )

[Harry Stahl]

Die Variante mit SHR ist compilierbar, ist auch schneller, aber das Ergebnis ist falsch, siehe anliegende Screenshots.

Das habe ich von Dir da verwendet:

Delphi-Quellcode:

procedure Draw32BitToBitmapNew(const BitOben: TBitmap; BitUnten: TBitmap);
var
   h,w,i: 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
         i := RGBA_Unten^[w].rgbBlue - (((Integer(RGBA_Unten^[w].rgbBlue - RGBA_Oben^[w].rgbBlue) * Integer(RGBA_Oben^[w].rgbReserved)) shr 8));
         if i < 0 then RGBA_Unten^[w].rgbBlue := 0 else RGBA_Unten^[w].rgbBlue := i;

         i := RGBA_Unten^[w].rgbGreen - (((Integer(RGBA_Unten^[w].rgbGreen - RGBA_Oben^[w].rgbGreen) * Integer(RGBA_Oben^[w].rgbReserved)) shr 8));
         if i < 0 then RGBA_Unten^[w].rgbGreen := 0 else RGBA_Unten^[w].rgbGreen := i;
         
         i := RGBA_Unten^[w].rgbred - (((Integer(RGBA_Unten^[w].rgbred - RGBA_Oben^[w].rgbred) * Integer(RGBA_Oben^[w].rgbReserved)) shr 8));
         if i < 0 then RGBA_Unten^[w].rgbRed := 0 else RGBA_Unten^[w].rgbRed := i;

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

[Harry Stahl]

Und die erste Variante ist nach wie vor nicht kompilierbar. Zwar akzeptiert der Compiler die erste Zeile, bei der zweiten sagt er aber "E2014: Anweisung erforderlich aber Ausdruck vom Typ Integer gefunden"

[mensch72]

Wenn der Compiler sagt, das da Irgendwo kein Integer ist funktioniert das mit "shr 8" nicht... morgen werfe ich ml kurz mein Delphi an und finde das "Syntax" Problem... muss ja meine Pascalsyntax "schulen".

Auch macht SHR Mist, bei negativen Zahlen... ich tippe es mal komplett als "unsigned int" ähhh "cardinal"... muss aber erst noch verstehen, "warum" du aktuell den Weg über negative werte gehst... meine Routine welche ich irgendwo habe macht die Größenprüfung irgendwie vor der Differenz und bearbeitet mit angepasster Folgelogik dann nur positive Werte...

Setze doch mal einen Breakpunkt auf den Zweig "wenn kleiner 0" und schreibe gib mir mal die Farb und Trasparenz-Werte als Beispiel. Konstruieren kann ich mir das auch, aber möchte mal deine Zahlen in meine Routine stecken.

[Medium]

Bei so vielen Operationen mit Bitmaps würde ich auch recht schnell zur schon erwähnten Graphics32 greifen. Insbesondere die Überblendungsoperationen sind da extrem flott umgesetzt, genaue Zahlen habe ich aber nicht an der Hand zum vergleichen. Parallel-Processing macht die von Hause aus zwar nicht, ließe sich aber bestimmt auf kleinen Umwegen auch machen. Wenn es dann überhaupt noch nötig ist.

[Harry Stahl]

Ich habe mal die Bilder was kleiner gemacht, damit ich sie noch in die Form integrieren kann (im Original sind sie ca. jeweils 30 MB groß, da weigert sich Delphi) und das Testprojekt mal hier hochgeladen.

Auf dem Screenshot kann man sehen: Alt gibt die Zeit für die Ursprungs-Procedure vor. Optimiert ist das, wo wir uns gerade bemühen (im Source jetzt gleich mit "Alt") und Par ist die Bearbeitung in Parallel.

Zeige "Ergebnis" zeigt das Ergebnis einer der 3 Berechnungsmethoden an, und Prüft bei Optimiert und Parallel, ob das Ergebnis gleich ist mit der Ursprungsfunktion.

Zur Info: Der Hintergrund ist ein Farbverlauf, das obere Bitmap ist in den Streifen Teiltransparent.

[jfheins]

Hast du es mal ohne die Prüfung auf i < 0 probiert? Der Fall sollte ja eigentlich nicht vorkommen

Ansonsten habe ich noch Vorschläge:
1. Termumformung, sollte aber eigentlich nicht schneller sein. Ist aber imho etwas verständlicher
RGBA_Unten^[w].rgbBlue := Cardinal((255 - RGBA_Oben^[w].rgbReserved) * RGBA_Unten^[w].rgbBlue + RGBA_Oben^[w].rgbReserved * RGBA_Oben^[w].rgbBlue) shr 8; etc. für die anderen Farben.

2. Nimm mal nicht immer die gleiche Variable i, sondern drei verschiedene Variablen. Dann können die drei Zeilen parallel ablaufen.
3. Fall die if-Abfrage doch nötig sein sollte, schreibe sowas:
RGBA_Unten^[w].rgbBlue := i and (not i shr 24) Effekt: Wenn der Wert negativ wird, dann wird das obere Byte des ints aus einsen bestehen. Durch das bitweise and wird der Wert zu 0. Du vermeidest aber das if, das auf Maschinenebene möglicherweise teuer ist.

4. Sagt wir "premultiplied alpha" etwas? Klingt erstmal komisch, ist aber eigentlich die sinnvollere Variante. Würde deinen Rechenaufwand auch hier reduzieren, aber deine Bilddaten müssten dafür natürlich angepasst werden.

[samso]

Ich habe einige sehr einfache Änderungen vorgenommen. Bei mir benötigt der Algorithmus dann nur noch die halbe Zeit. Das Ergebnis ist nicht identisch mit dem alten Algorithmus. Die Ursache liegt meiner Meinung nach im Floatingpoint-Rundungsalgorithmus begründet. Das Bild sieht aber nicht offensichtlich falsch aus.

Delphi-Quellcode:

procedure Draw32BitToBitmapSamso(const BitOben: TBitmap; BitUnten: TBitmap);
var
   h, w, i: Integer;
   RGBA_Unten, RGBA_Oben: PRGBQuad;
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
         i := RGBA_Unten^.rgbBlue - (RGBA_Unten^.rgbBlue - RGBA_Oben^.rgbBlue) * RGBA_Oben^.rgbReserved div 256;
         if i < 0 then RGBA_Unten^.rgbBlue := 0 else RGBA_Unten^.rgbBlue := i;

         i := RGBA_Unten^.rgbGreen - (RGBA_Unten^.rgbGreen - RGBA_Oben^.rgbGreen) * RGBA_Oben^.rgbReserved div 256;
         if i < 0 then RGBA_Unten^.rgbGreen := 0 else RGBA_Unten^.rgbGreen := i;

         i := RGBA_Unten^.rgbRed - (RGBA_Unten^.rgbRed - RGBA_Oben^.rgbRed) * RGBA_Oben^.rgbReserved div 256;
         if i < 0 then RGBA_Unten^.rgbRed := 0 else RGBA_Unten^.rgbRed := i;

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

[Harry Stahl]

Erst mal vielen Dank an Euch fürs mit überlegen, ich finde es echt spannend, hier die anderen Ansätze mal zu sehen. Jede der zuletzt genannten Varianten war immer ein weniger schneller als die Ausgangsfunktion.

Ich habe jetzt einfach mal bei ImageEn nachgesehen, die ich hier lizenziert habe, wie die das machen. Da ist das Bild zwar auch geringfügig unterschiedlich als meine Ausgangsfunktion, aber vielleicht war meine ja auch nicht korrekt.

Jedenfalls in Anlehnung an die ImageEn-Lösung kann man das hier so machen ist das ist dann mit 71 MS die bislang schnellste Lösung und toppt sogar die Parallel-Lösung. Da ist dann irgendwann anscheinend der Zeitbedarf für das Management des Threading größer, als der Zeitgewinn durch den Einsatz mehrerer Kerne. Insofern muss man sich genau ansehen, wann man die Parallelisierung einsetzt. Besserer Code geht also meistens doch noch vor Parallel-Bearbeitung. Wahrscheinlich lohnt sich die Parallelisierung eher bei Prozessen, die eh schon etwas länger dauern.

Delphi-Quellcode:

// Setz vorraus, dass die Bitmaps die gleiche Größe haben!!!
procedure Draw32BitToBitmap(const BitOben: TBitmap; BitUnten: TBitmap);
var
  h,w,i: 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
        (* Das war die Ausgangslösung
        i := Round (RGBA_Unten^[w].rgbBlue - ((RGBA_Unten^[w].rgbBlue - RGBA_Oben^[w].rgbBlue) / 255 * RGBA_Oben^[w].rgbReserved));
        if i < 0 then RGBA_Unten^[w].rgbBlue := 0 else if i > 255 then RGBA_Unten^[w].rgbBlue := 255 else RGBA_Unten^[w].rgbBlue := i;

        i := Round (RGBA_Unten^[w].rgbGreen - ((RGBA_Unten^[w].rgbGreen - RGBA_Oben^[w].rgbGreen) / 255 *  RGBA_Oben^[w].rgbReserved));
        if i < 0 then RGBA_Unten^[w].rgbGreen := 0 else if i > 255 then RGBA_Unten^[w].rgbGreen := 255 else RGBA_Unten^[w].rgbGreen := i;

        i := Round (RGBA_Unten^[w].rgbRed - ((RGBA_Unten^[w].rgbRed - RGBA_Oben^[w].rgbRed) / 255 * RGBA_Oben^[w].rgbReserved));
        if i < 0 then RGBA_Unten^[w].rgbRed := 0 else if i > 255 then RGBA_Unten^[w].rgbRed := 255 else RGBA_Unten^[w].rgbRed := i;
        *)

        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;

[mensch72]

super... das war eigentlich exakt das was ich dir gerade als "Berechnungslösung" vorschlagen wollte, denn auch wenn ich das vor Jahren woanders her kopiert habe... das sieht einfach schön klar aus

Ich würde aber eine zusätzliche Sicherheitsklammerung einführen, damit auch wirklich erst multipliziert wird und erst dann dividiert(shr 8) wird... das sollte genauer sein, wenn hier bicht absichtlich mit den BitUmschlag im Shift gerechnet wird.

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

Einen Versuch wäre es wert