Weichzeichnen mit RGB....aber wie?

MG80S

Guten Abend,

ich bin gerade dabei einen Filter zum Weichzeichnen zu schreiben. Wollte erstmal was einfaches versuchen. Habe mir das so vorgestellt:
Wenn ich Pixel(x;y) betrachte, schauen ich mir alle im Quadrat (x-1;y-1) bis (x+1;y+1) an und lasse diese 8 Pixel mit einem gewissen Prozentsatz einfliessen.
Soweit, sogut, aber wie kann ich die Farbwerte denn einfliessen lassen? Bei Graustufen wäre es ja relativ einfach, aber bei RGB?
Nehmen wir jetzt einfach mal nur zwei Pixel, die zu 50% eingehen. Setzt sich der RGB-Wert dann so zusammen?

rn = (r1+r2)/2;
gn = (g1+g2)/2;
bn = (b1+b2)/2;

Vielen Dank schonmal im Vorraus.

MG80S

Warum bitte wird "V o r r a u s" zensiert? (abgesehen davon, dass ein R zuviel ist)

finix

Für den Anfang würde ich einfach mal ganz naiv nach "Gaussian blur" & "algorithm" googlen..

SideWinder

MG80S schrieb:

Warum bitte wird "V o r r a u s" zensiert? (abgesehen davon, dass ein R zuviel ist)

Aus keinem weiteren Grund.

MfG SideWinder

MG80S

finix schrieb:

Für den Anfang würde ich einfach mal ganz naiv nach "Gaussian blur" & "algorithm" googlen..

Für den Anfang? Gaussian ist doch aber schon ziemlich heavy, oder täusche ich mich? Ich wollte erstmal was Einfaches versuchen, da die Performance auch sehr gut sein muss.

/Edit:
Okay, fürs Endresultat ist Gaussian wahrscheinlich auch das cleverste, aber auch mal so prinzipiell: Geht die Methode, die ich versucht habe zu beschreiben denn überhaupt(der Teil mit RGBs "mischen")?

Netzwerk-Latenz

Pixel vorher

Pixel nacher

Dürfte auch nicht so schwer sein sowas zu implementieren. Denke ich mal.

TomasRiker

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

MG80S

Danke für Eure Tips (besonders an Netzwerk-Latenz, nach fünf Min grübeln habe ich das System erkannt ).
Mit RGB-Werten aufteilen geht auch super, hatte nur beim Filtern der einzelnen Werte einen Fehler drin und es kamen komische "Kratzer" auf den Bildschirm. Jetzt geht es super, auch wenn ich bis jetzt nur 2 Pixel aneinander anpasse.
Nun zum Rest.....

DEvent

MG80S schrieb:

finix schrieb:

Für den Anfang würde ich einfach mal ganz naiv nach "Gaussian blur" & "algorithm" googlen..

Für den Anfang? Gaussian ist doch aber schon ziemlich heavy, oder täusche ich mich? Ich wollte erstmal was Einfaches versuchen, da die Performance auch sehr gut sein muss.

ist nicht heavy, es geht ( eigene erfahrungen, softwarepraktikum )
man brauch sich nur eine stunde hinzusetzen und schreiben.

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