Durchschnittsfarbe eines Bitmap "schnell" ermitteln

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

[Rollo62]

Zitat von 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.

So sehe ich das auch, siehe 2^8 = Platz für 256 Werte.

[Michael II]

Zitat von 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.

Nein das stimmt nicht. Kulturen hin oder her.

Schau noch einmal in den Code, um welchen es geht. Dort wird eine Variable r vom Typ integer auf 0 gesetzt. Und danach wird Pixel für Pixel geschaut, welcher Rotanteil vorliegt. Dieser Rotanteil wird jedes Mal zu r addiert.

Nun wollen wir herausfinden, wann r frühestens überläuft. r läuft in Kulturen wo der Rotanteil aller Pixel immer 0 ist gar nie über, da r konstant 0 bleibt. D.h. in solchen Kulturen kannst du unendlich viele Rotanteile zu r addieren.

Es gibt aber auch Kulturen (zum Beispiel bei gewissen Kulturen im Pferdekopfnebel), in welchen der Rotanteil aller Pixel immer maximal maxbyte = 11111111(bin) = 255(dec) ist.
Wenn du dir jetzt überlegen willst, wann es bei der Summenbildung frühestens knallt, dann musst du einen Taschenrechner zur Hand nehmen und eine 0 eintippen.

Nun addierst du 255 für Pixel 1, 255 für Pixel 2, 255 für Pixel 3...
Nach p Pixeln bist du bei p*255 angelangt.

Irgendwann fragst dich, wann p*255 > maxint erreicht wird.

Diese Ungleichung kannst du lösen:

p>maxint/255.

Die Lösung lautet: Nach p>maxint/255 Pixeln läuft r über.