Durchschnittsfarbe eines Bitmap "schnell" ermitteln

[KodeZwerg]

Zitat von Amateurprofi:

Hallo KodeZwerg:
Ich hab dir mal etwas zusammengestoppelt.
Aufruf mit GetAvgColor(Dateiname) oder GetAvgColor(Bitmap)
Mit TestGetAvgColor; hab ich das Ergebnis und die Performance getestet und mit der Funktion aus #3 verglichen.
Die zurückgegebenen Durchschnittsfarben sind identisch, die Ausführungszeiten sind dagegen höchst unterschiedlich.

Danke Amateurprofi, dein Code arbeitet zwar schneller aber liefert bei mir kein Ergebnis.
Ich habe ihn gegen den Turbo von TiGü antreten lassen, siehe Anhang.

Muss ich noch eine besondere Einstellung vornehmen damit mir Dein Code einen Farbwert über 0 liefert?

Getestet mit Delphi Rio, 32-bit build, Release, unter Windows 10 64bit aktuellste patches.

[Michael II]

Zitat von grizzly:

Interessante Diskussion. Da kommt mir aber noch eine abstruse Idee: Man macht ein "Resize" des Bildes auf 1x1 Pixel großes Bild und schaut sich dann nur noch dieses Pixel an. Läuft das Resize auf der GPU wäre das auch ganz schon flott.
Ich habe natürlich keine Ahnung, wieviel Mühe sich so ein Bildverkleinerungsalgo macht, wenn das Ziel nur noch 1 Pixel groß ist...

Viele Grüße
Michael

Halt doch noch rasch dazu:
Coole Idee... .

Funktioniert auch gut... und sicher schnell, u.v.a. auch auf dem TrillionK Monitor. Ich habe keine Zeit fürs Messen.

Die Werte sind (was ich auch erwartet habe, GrafikerInnen berechnen den Durchschnittswert wahrscheinlich eher über ein anderes Modell und etwas anders) nicht ganz gleich (wie beim RGB DS Rechnen). Bei einfarbigen Bitmaps aber natürlich identisch.

Man könnte natürlich statt auf ein 1x1 Pixel zu skalieren eine etwas grössere Zielbitmap wählen.

Der Code wird ultrakurz:


GDI+

Delphi-Quellcode:

uses GDIPOBJ, GDIPAPI;

  gr := TGPGraphics.Create( bmap );
  gr.ScaleTransform( 1/bmap.GetWidth, 1/bmap.GetHeight );
  gr.DrawImage( bmap, 0,0 );
  bmap.GetPixel(0,0,col);

[Jens01]

Zitat:

Bei ganz ganz ganz vielen Pixeln ist der Wert irgendwann so groß, dass die nächste Addition des kleinen Wertes, abgeschnitten wird.

r wird nicht größer als 255, oder?

[KodeZwerg]

So wie ich es verstanden habe fügt sich ein RBG wert aus 3 DWORDs zusammen.

[himitsu]

Es ist ein DWORD, dass aus 3+1 Bytes besteht

[KodeZwerg]

@Michael II
Nun passiert da was... aber mein Ergebniss ist falsch.

Delphi-Quellcode:

function GetAvgGDIColor(const Filename: string): TColor;
var
  gr: TGPGraphics;
  Bmap: TGPBitmap;
  col: TGPColor;
begin
  Result := 0;
  bmap := TGPBitmap.Create(Filename);
  try
    gr := TGPGraphics.Create( bmap );
    try
      gr.ScaleTransform( 1/bmap.GetWidth, 1/bmap.GetHeight );
      gr.DrawImage( bmap, 0,0 );
      bmap.GetPixel(0,0, col);
      Result := RGB(GetRValue(col), GetGValue(col), GetBValue(col));
    finally
      gr.Free;
    end;
  finally
    bmap.Free;
  end;
end;

Falls Du Dich nochmal reinklinken könntest um mich zu korrigieren, das wäre nett!

Zitat von himitsu:

Es ist ein DWORD, dass aus 3+1 Bytes besteht

Mein Fehler!

[dummzeuch]

Zitat von KodeZwerg:

Auf Int64 ist es bereits umgestellt, aber auch das hat seine Grenzen.
Mir fehlt da die Erfahrung wie man es "abfangen" könnte damit die Berechnung einfach ab einer gewissen Zahl aufhört weiterzuzählen, würde es aber gerne zur Sicherheit mit einbauen.

Man könnte auf einen möglichen Überlauf prüfen und Zwischen-Mittelwerte bilden, die dann hinterher zusammengerechnet werden.

Mathematisch gilt ja:

Code:

 a1 + a2 + a3 + a4    a1    a2    a3    a4     a1 + a2     a3 + a4
------------------- = --- + --- + --- + --- = --------- + ---------
      4                4     4     4     4        4           4

Und bei hohen Zahlen sind evtl. Rundungsfehler eher unwichtig.

[Rollo62]

Zitat von Michael II:

maxint=2^31-1 speichern.
s > sqrt((2^31-1)/255))

Oha verrechnet, Du hast ja Recht
Habe auf die Schnelle mit Cardinal gerechnet, und mangels Taschenrechner nur geschätzt.

Stimmt Integer ist signifikant kleiner, trotzdem würde ich mit dem vollen Umfang und 8-Bit rechnen, wieso -1 ?
s > sqrt( (2^31)/256 ) = sqrt((2^31)/2^8 ) = sqrt( (2^31-8) ) = sqrt( 2^23 ) = 2^( 23 / 2 ) = 2^11.5 = 2896
Also ich komme auf 2896x2896, ist wirklich zu wenig.

[Michael II]

Zitat von Rollo62:

Zitat von Michael II:

maxint=2^31-1 speichern.
s > sqrt((2^31-1)/255))

Oha verrechnet, Du hast ja Recht
Habe auf die Schnelle mit Cardinal gerechnet, und mangels Taschenrechner nur geschätzt.

Stimmt Integer ist signifikant kleiner, trotzdem würde ich mit dem vollen Umfang und 8-Bit rechnen, wieso -1 ?
s > sqrt( (2^31)/256 ) = sqrt((2^31)/2^8 ) = sqrt( (2^31-8) ) = sqrt( 2^23 ) = 2^( 23 / 2 ) = 2^11.5 = 2896
Also ich komme auf 2896x2896, ist wirklich zu wenig.

Cardinal ist in D32bit und D64bit 32Bits lang, ohne Vorzeichen. Du hast also rund zwei Mal so viele Zahlen>0 wie bei integer - und damit sqrt(2) mal mehr maximale Bitmap-Seitenlänge.

Zu deiner Frage wegen wieso -1. Du hast das Vorzeichenbit vergessen. Die grösste positive integer Zahl (maxint) sieht so aus m = 011111111 11111111 11111111 11111111. Wenn du zu m 1 addierst, hättest du 10000000 00000000 00000000 00000000 = 2^32. Die Zahl vor 2^32 hat damit den Wert maxint=2^32-1. 2^32 entspricht bei integer dem negativen Wert -2^32.
Oder wenn du's lieber via geometrische Reihe rechnen willst:
011111111 11111111 11111111 11111111 hat den Wert
s = 2^0+2^1+2^2+....+2^30
und 2s = 2^1+...+2^31
Subtrahierst du von Zeile 2 Zeile 1 ergibt sich s=2^31-2^0 = 2^31-1.

Zu deinem Einwand, man sollte durch 2^8=256 teilen. Kurze Antwort: Nein. Lange Antwort: r liegt im Bereich [0..255] und nicht im Bereich [0..256]. Du musst dir also überlegen wie oft 255 in 2^32-1 Platz hat => (2^32-1)/255 Mal.

[himitsu]

Nein, man muß gucken, wie oft 256 Platz hat,
denn die 0 ist auch ein gültiger Wert.

1..255 bzw. 0..254 wäre Platz für 255.



Aber keine Sorge, auch andere vergessen die 0 gern.
Daher wurde die Zahl 0 in vielen Kulturen auch erst sehr spät erfunden.