Durchschnittsfarbe eines Bitmap "schnell" ermitteln

[Rollo62]

Zitat von Michael II:

In einigen der hier geposteten Beispiele befürchte ich bei grossen Bitmaps Integerüberlauf in r,g,b.

Ja das sprang mir auch gerade ins Auge.
Trotzdem, theoretisch gibt es Überläufe erst ab Bildgrößen von 24000x24000.
Ich denke es ist noch ein bischen Zeit bis dahin

Aber ich würde auch einen Test o.ä. anlegen, der aufpoppt falls solche Größen mal erreicht werden.

[himitsu]

64 Bit compiliert, kannst Int64 benutzen und hast genug Platz.

Hier wird es ja von der CPU behandelt.

In Win32 machen das Funktionen in der System.pas.
OK, die Addition geht dennoch recht schnell und am Ende das eine DVI, da stört der etwas langsamere Code kaum.

[TiGü]

Bitte alle Kirchen im Dorf lassen, er verwendetet das für Desktophintergründe.

[Michael II]

Zitat von Rollo62:

Zitat von Michael II:

In einigen der hier geposteten Beispiele befürchte ich bei grossen Bitmaps Integerüberlauf in r,g,b.

Ja das sprang mir auch gerade ins Auge.
Trotzdem, theoretisch gibt es Überläufe erst ab Bildgrößen von 24000x24000.
Ich denke es ist noch ein bischen Zeit bis dahin

Aber ich würde auch einen Test o.ä. anlegen, der aufpoppt falls solche Größen mal erreicht werden.

Zitat von TiGü:

Bitte alle Kirchen im Dorf lassen, er verwendetet das für Desktophintergründe.

Und genau deshalb ist es wichtig, dass der Fragende eine wie verlangt schnelle und funktionierende Lösung hat.
Schneller als via Scanline geht's fast nicht.
Bei Verwendung von int64 muss man - wie himitsu schreibt - schon kurz nachdenken, wie das Verhalten in Bezug auf Speed unter 32 bzw. 64 bit ist.

Bei Verwendung von integer für die rgb Werte stösst die Funktion auch bei diesem "Kirche im Dorf Verwendungszweck" zu rasch an ihre Grenzen.
r kann maximal den Wert maxint=2^31-1 speichern.
Wenn in jedem Pixel der Bitmap der Rotwert 255 beträgt, kannst du also maximal trunc((2^31-1)/255) Pixelwerte zusammenzählen.
Bei einer quadratischen Bitmap bist du bei einer Seitenlänge s > sqrt((2^31-1)/255)) am Ende der Fahnenstange angelangt.
Eine 2901*2901 Bitmap ist also gerade noch berechenbar. Grösser darf sie nicht sein.
Oder direkt auf den Anwendungszweck bezogen:
4K Monitor: r erreicht maximal 3840*2160*255 = 2’115’072’000 < 2^31-1, geht gerade noch.
Bereits bei meinem 8K Monitor, den ich nicht habe, fliegt's einem um die Ohren.
Es ist mir bewusst, dass wir hier einen "Nebenschauplatz" diskutieren.
Aber es ist wichtig, dass Code, welcher die eigenen vier Wände verlässt so geschrieben wird, dass er auch in einer Flugzeugsoftware eingebaut zuverlässig funktioniert.

[TiGü]

Bei einem einfarbigen Hintergrund gibt es aber kein Bitmap-Wallpaper, da wird ein RGB-Wert aus der Registry gelesen.
Wer macht sich denn einen 8K Hintergrund als einfarbiges (!) Bitmap?

Wer wirklich sicher gehen will, der ändert sich den Code halt. Kirchen -> Dörfer!

[KodeZwerg]

Ja @TiGü, ich nutze das ausschließlich für das Theming Projekt aber gebe natürlich Recht das es diese "8k * 1 Farbe" Möglichkeit irgendwie geben könnte. Sinnfrei aber ja.
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.

Delphi-Quellcode:

var
  r: Int64;
  i: Cardinal;
begin
  r := 0;
  for i := 0 to High(Cardinal) do
  begin
    if r < High(Int64) then
      r := r + 1;
  end;
end;

Macht man das so in etwa? (Nur hier im Edit getippst...)

[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

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

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

[Michael II]

Zitat von TiGü:

Bei einem einfarbigen Hintergrund gibt es aber kein Bitmap-Wallpaper, da wird ein RGB-Wert aus der Registry gelesen.
Wer macht sich denn einen 8K Hintergrund als einfarbiges (!) Bitmap?

Wer wirklich sicher gehen will, der ändert sich den Code halt. Kirchen -> Dörfer!

OK ich hatte überlesen, dass KodeZwerg den Durchschnittswert aus einer einfarbigen Bitmap errechnen wollte. Wenn dem echt so ist (ich verstand sein Anliegen so, dass er den RGB-Durchschnittswert eines Bild berechnen wollte; das macht ja deine Funktion auch), dann muss KodeZwerg den Durchschnitt nicht berechnen. Bei einem einfarbigen Bitmap reicht es irgend ein Pixel zu nehmen, da ja dann alle gleich sind. Dann gibt es auch beim neuen "TrillionK Monitor" in der Nähe von Alpha Centauri exakt 0 Probleme. Ich glaube wir schreiben aneinander vorbei, ich habe das Problem offensichtlich komplett überschätzt, ich weiss nicht wieso, ich bin hier raus, die meisten sind ja total glücklich .