Weichzeichnen mit RGB....aber wie?

TGGC

TomasRiker schrieb:

Um die Frage zu beantworten:
Ja, man muss die Berechnungen für jeden Farbkanal (R, G, separat durchführen.

Na man kann auch so Scherze machen:
F = ( ( F1 >> 1 ) & 0x7f7f7f7f ) + ( ( F2 >> 1 ) & 0x7f7f7f7f )

Klappt halt nur, wenn alle Pixel mit 1 / 2^n gewichtet werden.

Bye, TGGC Deine Unterstützung wird gebraucht!

MG80S

TGGC schrieb:

F = ( ( F1 >> 1 ) & 0x7f7f7f7f ) + ( ( F2 >> 1 ) & 0x7f7f7f7f )

Versuch grad selber dahinterzusteigen (kannst natürlich trotzdem erklären, wenn Du willst ). Nur soviel: Ist das RGBA oder warum 4 mal 7F ?

MG80S

Wow, warum auch immer (das gehört noch geprüft....), das geht ja super.
Bin noch nicht ganz dahintergestiegen warum (ab einer bestimmten Größe der Zahl platzt mir der Kopf ), bleibe aber dran. Dank Dir...

TGGC

Beim Shiften "schmieren" die LSB jeder Farbe in die MSB der "benachbarten Farbe". z.b. Grün Bit 0 wird Rot bit 7. Daher müssen diese jeweils ausmaskiert werden. Rechne die Konstane mal in eine Binärzahl um.

Bye, TGGC (Für echte Fans)

MG80S

Ah, okay, ungefähr verstanden. Aber das funktioniert immer nur für 2, die "addiert" werden, ne? Wenn ich also 4 habe (a,b,c,d) kann ich mit:
(axb)x(cxd) vogehen, aber bei Werten ungleich 2^n sieht's schlecht aus, oder? (Hattest Du ja eigentlich auch geschrieben...)

Nungut, ich habe jetzt erstmal ein Weichzeichner realisiert, der folgende "Aufteilung" vornimmt:

0 0 1 0 0
0 1 2 1 0
1 2 3 2 1
0 1 2 1 0

Der ist allerdings ziemlich langsam (inkl. Farbwerte aus Buffer holen und neue in Buffer schieben 165ms). Ich habe allerdings nur 40ms Zeit. Ich kann zwar am Drumherum noch bissel was optimieren, aber sieht vielleicht im "Kern" noch jemand Optimierungsbedarf?

Zur Erläuterung der Indizes von red,green,blue:

x x 0 x x
x 1 2 3 x
4 5 6 7 8
x 9 10 11 x
x x 12 x x

uint32 i=0;
	uint32 r,g,b;
	BRect *outDim=((PluginManager *)pluginManager)->GetOutputRect();
	int xmax = outDim->IntegerWidth();
	for (i=0; i<size;i++)
	{
		red[0] = (inbuffer[i-2*xmax] & 0x00ff0000)>>16;
		green[0] = (inbuffer[i-2*xmax] & 0x0000ff00)>>8;
		blue[0] = inbuffer[i-2*xmax] & 0x000000ff;
		red[1] = (inbuffer[i-xmax-1] & 0x00ff0000)>>16;
		green[1] = (inbuffer[i-xmax-1] & 0x0000ff00)>>8;
		blue[1] = inbuffer[i-xmax-1] & 0x000000ff;
            //usw. -> alle umliegenden Farbwerte werden rausgeholt
		red[12] = (inbuffer[i+2*xmax] & 0x00ff0000)>>16;
		green[12] = (inbuffer[i+2*xmax] & 0x0000ff00)>>8;
		blue[12] = inbuffer[i+2*xmax] & 0x000000ff;
            //jetzt anteilmässig addieren und "Durchschnitt" bilden
		r = (int) (red[0]+red[1]+red[3]+red[4]+red[8]+red[9]+red[11]+red[12]+red[2]+red[5]+red[7]+red[10]+red[2]+red[5]+red[7]+red[10]+red[6]+red[6]+red[6])/19;
		g = (int) (green[0]+green[1]+green[3]+green[4]+green[8]+green[9]+green[11]+green[12]+green[2]+green[5]+green[7]+green[10]+green[2]+green[5]+green[7]+green[10]+green[6]+green[6]+green[6])/19;
		b = (int) (blue[0]+blue[1]+blue[3]+blue[4]+blue[8]+blue[9]+blue[11]+blue[12]+blue[2]+blue[5]+blue[7]+blue[10]+blue[2]+blue[5]+blue[7]+blue[10]+blue[6]+blue[6]+blue[6])/19;
		outbuffer[i] = (r<<16)+(g<<8)+b;
	}

Bei den vielen Additionen war ich mir nicht sicher, was schneller ist:

3a oder a+a+a ?
2(a+b+c+d) oder (a+a+b+b+c+c+d+d)?

Danke fürs Lesen, ist wohl etwas kryptisch geworden...

TGGC

Für /4 gehts analog >> 2 und 3f3f3f3f

Bye, TGGC Deine Unterstützung wird gebraucht!

aaaabyx

Gratulation, dies ist Thread #100.000...

MG80S

Oho, danke :p

TGGC

Na und?

Bye, TGGC (NP Intelligenz)

MG80S

Naja, ist doch nett. Nichts Aufregendes, aber ein nettes "Feature".
So ein bisschen wie ein Lächeln im Supermarkt, nichts sonderlich Bedeutsames, aber ein netter Klecks Farbe am Wegrand....*laber*....

Habs noch bissel optimiert bekommen dankBitoperationen. Bin ausserdem (vorerst) auf folgendes Schema zurück:

1 2 1
2 4 2
1 2 1

Das lässt sich schneller berechnen und da es insgesamt 16 sind auch fixer teilen. Sind zwar immer noch 75ms aber immerhin schonmal näher dran an der 40.
Danke für die Tips. M