[gelöst] Bildrotation grafischer Fehler

[TGGC]

Little Programmer schrieb:

ja, mathematisch müsste ja auch sowohl meine erste, wie auch meine zweite Möglichkeit funktionieren. Meine Frage ist ja, warum tun es beide auf die selbe Weise nicht?

Weil sie mathematisch gesehen nicht funktioniert. Wenn z.b. die Matrix eine Streckung enthielte, dann wuerde eine Textur mit 4x4 Pixel auf dem Bildschirm 20x20 Pixel einnehmen - deine tolle Methode wuerde aber statt 400 Pixeln nur 16 zeichnen. Und da fragst du noch, wo die Loecher herkommen? f'`8k

Gruß, TGGC (Was Gamestar sagt...)

[rapso]

obwohl die sache mathematisch natuerlich funktioniert und richtig sein wuerde, rechnest du hier leider nicht mit unendlicher genauigkeit, sondern mit pixel-einheiten, beim rotieren wirst du also immer von float auf int runden und dabei dabei werden an manchen stellen pixel zusammenfallen und die fehlen dann an anderen stellen.
die transformation inverse zu machen, also fuer das ziel die passenden quell-pixel suchen verhindert dass du luecken hast, aber es wird bei der rotation dennoch vorkommen, dass dafuer manche pixel aus dem quell-bild garnicht vorkommen, jedoch faellt das weniger auf.

[TGGC]

rapso schrieb:

obwohl die sache mathematisch natuerlich funktioniert und richtig sein wuerde, rechnest du hier leider nicht mit unendlicher genauigkeit, sondern mit pixel-einheiten

Es ist ja nicht so, das die Mathematik im Computer nicht definiert waere und dann irgendwelche zufaelligen Fehler entstehen. Diese Fehler existieren nicht nur praktisch, sie ergeben sich schon im theoretischen Modell, mit dem der Computer arbeitet. Der Computer verpasst nicht irgendwelche Pixel, weil er falsch gerundet hat. Er hat natuerlich immer korrekt gerundet, ansonsten waere er defekt und nicht zu gebrauchen. Der Fehler liegt an der Stelle wo jemand dilletantisch versucht affine Transformationen in einem Computerprogramm umzusetzen. f'`8k

Gruß, TGGC (Was Gamestar sagt...)

[rapso]

TGGC schrieb:

rapso schrieb:

obwohl die sache mathematisch natuerlich funktioniert und richtig sein wuerde, rechnest du hier leider nicht mit unendlicher genauigkeit, sondern mit pixel-einheiten

Es ist ja nicht so, das die Mathematik im Computer nicht definiert waere und dann irgendwelche zufaelligen Fehler entstehen.

Ja, dann solltest du lieber darauf bezug nehmen statt zu behaupten etwas funktioniert schon rein mathematisch nicht.

Diese Fehler existieren nicht nur praktisch, sie ergeben sich schon im theoretischen Modell, mit dem der Computer arbeitet. Der Computer verpasst nicht irgendwelche Pixel, weil er falsch gerundet hat. Er hat natuerlich immer korrekt gerundet, ansonsten waere er defekt und nicht zu gebrauchen.

Ich sehe du hast meinen text sehr schnell aufgefasst.

Der Fehler liegt an der Stelle wo jemand dilletantisch versucht affine Transformationen in einem Computerprogramm umzusetzen.

Ja, jeder ist irgendwo dillenantisch. Traurig wird es wenn jemand auf seinem niveau stehen bleibt, da warst du gerade echt vorbildlich.

[TGGC]

Nach deiner Logik funktioniert ein Computer an sich schon rein mathematisch nicht. Das ist aber Quatsch. Er kann halt keine natuerlichen Zahlen oder reelen Zahlen, aber er hat ein anderes mathematisches Modell. Und dieses Modell ist in sich schluessig und funktioniert auch korrekt. Mit dieser Mathematik funktionieren einige Sache und andere nicht.

Aber da du ehh schon wieder auf deinen ich bin Mod und habe eh recht Trip bist - Guten Tag. f'`8k

Gruß, TGGC (Was Gamestar sagt...)

[Little Programmer]

@ rapso und @ TGGC, sorry das ich das jetzt sagen muss, aber ihr habt mal total am Thema vorbeigeschrieben.
@ TGGC, wie kommst du bitte schön auf die Idee, dass ich das Bild strecken würde? Das Ziel- und Quellbild sind gleich groß. es war nirgends von einer Streckung die Rede.
@ rapso, wie ich glaube ich schon mehrmals hier im Topic geschrieben habe und wie es auch auffällig in der Hälfte des Quelltextes steht, runde ich meine Koordinaten nicht sondern nutze oversampling, um Pixel über mehrere pixel verteilt an der Korrekten Stelle anzuzeigen. Generell ist die gesamte Berechnung möglichst rundungsfrei auf doubles beschränkt, damit keine Rundungsfehler irgendeiner Form auftreten.

Invers tranformieren funktioniert aus den selben Fehlern wie die andere nicht, da im Zielbild bei den aktuellen beiden Berechnungsarten Pixel fehlen, daran würde sich dann gar nichts ändern. Ich versuche nun eine dritte Berechnungsart und bedanke mich hier erstmal für die Hilfe und erkläre das Thema für gelöst. Neue Erkenntnisse kommen hier wohl nicht mehr zustande.

[rapso]

Little Programmer schrieb:

Invers tranformieren funktioniert aus den selben Fehlern wie die andere nicht, da im Zielbild bei den aktuellen beiden Berechnungsarten Pixel fehlen, daran würde sich dann gar nichts ändern.

das ist nicht moeglich, man setzt pixel fuer pixel, wie soll da ein pixel fehlen?

[hustbaer]

Little Programmer schrieb:

Invers tranformieren funktioniert aus den selben Fehlern wie die andere nicht, da im Zielbild bei den aktuellen beiden Berechnungsarten Pixel fehlen, daran würde sich dann gar nichts ändern. Ich versuche nun eine dritte Berechnungsart und bedanke mich hier erstmal für die Hilfe und erkläre das Thema für gelöst. Neue Erkenntnisse kommen hier wohl nicht mehr zustande.

Natürlich funktioniert invers transformieren.
Und ganz egal ob du mit Nearest-Pixel Filter oder Bilinear/Qubisch/... arbeitest, wenn du vom rotierten Bild auf das Original zurückrechnest hast du keinen Schottenrock mehr.
Probier's einfach mal aus.

[Little Programmer]

Habe eine andere Lösung gefunden, die das Bild fehlerfrei rotiert. Einmal habe ich eine Rechenleistung sparende Drehberechnung, welche nur einen einzigen Punkt drehen muss und aus dem Drehwinkel und der Position dieses Pixels die Positionen der anderen Pixel berechnet. Und zweitens fiel mir ein simpler aber funktionierender Trick ein.

//PosX und PosY sind doubles und enthalten nun schon die Koordinaten des neuen Pixels

            //Punkt
            PrintAA(bmpsmall, PosX, PosY, x, y, R, G, B, A);
            //Ein Viertel weiter
            PosX += 0.25;
            PosY += 0.25;
            PrintAA(bmpsmall, PosX, PosY, x, y, R, G, B, A);
            //Eine Hälfte weiter
            PosX += 0.25;
            PosY += 0.25;
            PrintAA(bmpsmall, PosX, PosY, x, y, R, G, B, A);
            //Drei Viertel weiter
            PosX += 0.25;
            PosY += 0.25;
            PrintAA(bmpsmall, PosX, PosY, x, y, R, G, B, A);

Durch dieses Weiterrücken fülle ich den Leerraum zwischen zwei Pixeln vollständig auf. Alle 0.25-Pixel wird nun ein Punkt gesetzt. Auch wenn jeder Punkt so viermal gesetzt wird, wieht man dies im Endbild nicht. Dies ist nun perfekt farbecht mit Oversampling gedreht.

[hellihjb]

Brillant!

[hustbaer]

@Little Programmer:
Das meinst du jetzt hoffentlich nicht ernst...?