Prüfung eines Bitmaps auf Transparenz (gehts noch schneller)?

[Harry Stahl]

Derzeit verwende ich folgende Methode, um ein 32-bit-Bitmap auf Vorhandensein eines (Teil-) Transparenten Pixels zu prüfen:

Delphi-Quellcode:

function HasTransparentRGBAValues (const bm:TBitmap): Boolean;
var
  x, z: Integer; RGBA: pRGBALine;
begin
  Result := FALSE;
  RGBA := bm.Scanline[bm.Height-1];
  z := bm.Width * bm.Height;

  for x := 0 to z-1 do begin
    if RGBA^[x].rgbReserved <> 255 then begin
      EXIT (TRUE);
    end;
  end;
end;

Bei einem Nicht transparentem Bild in den Ausmaßen 4244x2819 Pixel benötigt die Routine hier auf meinem Rechner ca. 80 MS um das ganze Bitmap zu prüfen, was ziemlich viel Zeit ist.

Kennt jemand da evtl. eine noch schnellere Methode als die oben dargestellte?

[Delphi-Laie]

Zitat von Harry Stahl:

Delphi-Quellcode:

function HasTransparentRGBAValues (const bm:TBitmap): Boolean;
var
  x, z: Integer; RGBA: pRGBALine;
begin
  Result := FALSE;
  RGBA := bm.Scanline[bm.Height-1];
  z := bm.Width * bm.Height;

  for x := 0 to z-1 do begin
    if RGBA^[x].rgbReserved <> 255 then begin
      EXIT (TRUE);
    end;
  end;
end;

Warum hat die Funktion nie die Möglichkeit, true zurückzuliefern?

Edit: OK, das wird wohl im Exitparameter realisiert - diese Möglichkeit war mir neu.

[Der schöne Günther]

Parallelisieren?

[Harry Stahl]

Zitat von Der schöne Günther:

Parallelisieren?

Bin mir da nicht so sicher, wegen des Overheads. Hatte ich zwar schon mal gemacht, allerdings zeigt mir AQtime seltsame Messwerte an (0,3 MS, was nicht sein kann) und bei einem Extra-Test-Projekt schwanken die einzelnen Testergebnisse zwischen 28 und 56 MS:

Delphi-Quellcode:

type
  TRGB32 = packed record
    B, G, R, A: Byte;
  end;

  TRGB32Array = packed array[0..MaxInt div SizeOf(TRGB32)-1] of TRGB32;
  PRGB32Array = ^TRGB32Array;

function HasTransparentRGBAValuesx (const bm:TBitmap): Boolean;
var
  LineLen: Integer; found: boolean;
  FirstLine : PRGB32Array;
begin
  Found := false;
  if bm.Width = 0 then exit;

  FirstLine := bm.ScanLine[0];
  LineLen := - bm.width;

  TParallel.For (0, bm.Height-1, procedure (y:Integer; S: TParallel.TLoopState)
  var
    x, p: Integer;
  begin
    if not s.ShouldExit then begin
      P := y*LineLen;
      for x := 0 to bm.Width-1 do begin
        if FirstLine[P+x].A <> 255 then begin
          found := true;
          s.Break;
          break;
        end;
      end;
    end;
  end);

  Result := found;
end;

Insofern wäre mir hier eine Variante ohne Parallelisierung mit eindeutig besseren Ergebnissen lieber

[Luckie]

Bitmap komplett in den Speicher laden, damit man keine Festplattenzugriffe hat und dann mit zwei Threads von vorne und hinten prüfen?

[jaenicke]

Ich hätte schon Ideen, aber dafür wäre ein Beispielbild sehr gut. Ohne Photoshop kenne ich auf Anhieb kein Tool, mit dem ich einer Bitmap einen Alphakanal hinzufügen könnte.

[Uwe Raabe]

Das TParallel.For über die 2819 Zeilen verursacht wahrscheinlich mehr Overhead als die Parallelisierung wettmachen kann. Wenn das ganze Bild ca. 80 ms braucht, dann sind das pro Zeile (also pro Iteration) ca. 0,03 ms. Das ist ein ganz schlechtes Verhältnis. Besser auf deutlich weniger Durchläufe beschränken und jede Iteration über ca. 100-500 Zeilen laufen lassen. Das sind dann pro Task ca. 3-15ms. Mit genügend freien Kernen sollte das merkbar sein.

[Harry Stahl]

Zitat von jaenicke:

Ich hätte schon Ideen, aber dafür wäre ein Beispielbild sehr gut. Ohne Photoshop kenne ich auf Anhieb kein Tool, mit dem ich einer Bitmap einen Alphakanal hinzufügen könnte.

Na, sowas sollte ja wohl jedes Grafikbearbeitungsprogramm drauf haben (in meinem Programm - PixPower - wählt man dazu einfach im Dropdown-Schalter "Farbe" unter Menü "Farbtiefe" 32 Bit, siehe anliegenden Screenshot).

Photoshop braucht man dafür wirklich nicht.

Aber wie auch immer, habe mal die Demo so verändert, dass die Grafik zur Laufzeit erzeugt wird (will hier keine 45 MB-Grafikdatei beifügen).

Mit den Schaltern Standard und Parallel kann man die Geschwindigkeit testen, wenn keine Transparenz vorhanden ist. Mit dem Schalter "SetTransparency" macht man eine Zeile transparent und kann dann die Routinen noch mal ausführen.

Projekt anliegend.

[Harry Stahl]

Zitat von Uwe Raabe:

Das TParallel.For über die 2819 Zeilen verursacht wahrscheinlich mehr Overhead als die Parallelisierung wettmachen kann. Wenn das ganze Bild ca. 80 ms braucht, dann sind das pro Zeile (also pro Iteration) ca. 0,03 ms. Das ist ein ganz schlechtes Verhältnis. Besser auf deutlich weniger Durchläufe beschränken und jede Iteration über ca. 100-500 Zeilen laufen lassen. Das sind dann pro Task ca. 3-15ms. Mit genügend freien Kernen sollte das merkbar sein.

Ja, wäre eine mögliche Verbesserung. Doch damit steigt die Komplexität wieder an und es wird so ein unschönes unleserliches Ungetüm draus. Und ob es schneller ist?

Insofern wäre mir eine Standard-Lösung lieber, z.B. per ASM.

Kenne mich mit Assembler aber leider nicht so gut aus.
Aber hier muss ja letztlich nur über einen zusammenhängenden Speicherbereich, jeweils in Abständen von 4 Byte geprüft werden, ob das Byte dort <> 255 ist.

Nichts anderes macht ja im Prinzip meine Standard-Methode. Aber gibt es da nicht so einen Super ASM-Befehl, der das in einem Rutsch ohne Iteration erledigen kann?

[BUG]

Das mit der gröberen Aufteilung sollte man probieren.
Eventuell könnte man mit den Vektoreinheiten (SSE) noch was heraushole. Das wird dann aber haariger (kA. wie weit Delphi von alleine vektorisiert).

Edit:

Zitat von Harry Stahl:

Doch damit steigt die Komplexität wieder an und es wird so ein unschönes unleserliches Ungetüm draus. Und ob es schneller ist?[...] Insofern wäre mir eine Standard-Lösung lieber, z.B. per ASM.

Frei nach Herb Sutter "Free lunch is over". Parallelisieren ist die Standard-Lösung.
Und dein Problem ist wirklich noch einfach zu parallelisieren