Diskussion:Rasterung von Linien

message: Bezüglich Abgrenzung zum Hauptartikel Bresenham-Algorithmus siehe Benutzer Diskussion:PeterFrankfurt#Weiteres Vorgehen --Phrood 11:56, 1. Mär. 2007 (CET)

message: Also mein Prof an der Uni hat immer die Devise ausgegeben, "Es gibt keine Probleme, nur Lösungen". Entsprechend war dieses Wort in Diplom- und Doktorarbeiten strengstens verpönt, schon gar in Überschriften... --PeterFrankfurt 00:44, 10. Mär. 2007 (CET)
replies: text: Dieser Artikel ist keine Diplomarbeit, sondern Vulgarisierung. Selbst Foley verwendet als Überschrift "Additional Issues". Besserer Vorschlag? --Phrood 00:50, 10. Mär. 2007 (CET)
replies: text: Wenn man genau hinschaut, sind von den drei Unterpunkten dieses Kapitels nur anderthalb wirkliche Probleme, der Rest zusätzliche Features. Daher tendiere auch ich eher in die Richtung der wörtlichen Übersetzung wie "Zusätzlich zu beachtende Punkte", aber das ist arg holprig und schreit nach eleganterer Formulierung. --PeterFrankfurt 16:18, 10. Mär. 2007 (CET)
thread_title:  "Probleme" 

message: Bei Bresenham in den Formeln für Delta-O und Delta-NO scheint mir ein Fehler zu stecken: Während für den Punkt M in den Zeilen davor korrekt die y-Koordinate als (yi+1/2) angegeben ist, tauchen hier (yi+1/2) für O und (yi+3/2) für NO auf. M. E. müssten hier (yi) und (yi+1) stehen.
Außerdem argumentiert Bresenham doch gerade nicht mit diesem eindimensionalen Abstand in reiner y-Richtung zwischen den O- und NO-Punkten und M (bzw. der Ideallinie), sondern zweidimensional, hoch geometrisch mit dem senkrecht zur Ideallinie gemessenen Abstand der beiden Alternativpunkte. Gerade an dieser Stelle, wo es ja um den "reinen Bresenham" geht, sollte man das nicht verwischen.
Und wo wir schon dabei sind: Dass bei der Definition von F(x,y) die Delta-y und Delta-x die selben wie im Kapitel davor sind, sollte man vielleicht doch ausdrücklich daneben schreiben.  --PeterFrankfurt 13:26, 28. Mär. 2007 (CEST)
replies: text: Ich habe mich dafür entschieden, die Midpoint-Formulierung zu verwenden, weil sie IMO einfacher ist als die von Bresenham. Bei den Formeln kann ich keinen Fehler finden. Man will ja d_{i+1} - d_i berechnen, dazu muss man eben die Koordinaten des übernächsten Punkts betrachten, also je nachdem \textstyle (x_i+2, y_i+\frac{1}{2}) oder \textstyle (x_i+2, y_i+\frac{3}{2}). --Phrood 17:09, 28. Mär. 2007 (CEST)
thread_title:  Formeln Delta-O und Delta-NO 

message: Diese Kandidatur läuft vom 22. April bis zum 12. Mai
Platz 3 in der Gesamtwertung, Platz 2 in der Sektion I. An dieser Stelle Danke für die hilfreichen Reviews. Enthaltung, da Autor. --Phrood 18:01, 22. Apr. 2007 (CEST)
replies: text: Zu 1) Implizite Form. Soll ich das verlinken? Es klingt so kompliziert... 2) Man iteriert nur über die Hälfte der Linie und färbt bei jedem Schritt die beiden symmetrischen Pixel auf einmal ein. Ich ergänze das noch. 3) Die Angabe von Geschwindigkeiten/Rechenoperationen ist problematisch. Sie hängen davon ab, wie der konkrete Code aussieht, welche Faktoren man für Additionen und Multiplikationen vergibt etc., so etwas ist immer sehr grob und subjektiv. Z.B. haben Wu/Rokne für ihr Doppelschrittverfahren eine Geschwindigkeitssteigerung von 100% gegenüber Bresenham angegeben, und diese Angabe wurde von Boyer/Bourdin später auf 15% relativiert, weil sie eine andere "Messmethode" verwendet haben. Daher möchte ich lieber keine Geschwindigkeiten angeben. --Phrood 00:44, 23. Apr. 2007 (CEST)
replies: text: Zu 1) Die Verlinkung wäre hier tatsächlich wohl eher kompliziert als nützlich. Ich war darauf gekommen, da sich „[...] eine andere Form der Geradengleichung“ irgendwie unwissenschaftlich liest und somit gar nicht zum Gesamteindruck des Artikels passt. Vorschlag: „[...] wird eine Form der Geradengleichung verwendet, die/mit der {Grund für diese Form der Gleichung}“ Zu 2) Prima. So versteh' ich es. Zu 3) Okay, das sehe ich ein. Damit gibt es von mir jetzt auch die angekündigte, euphorische Zustimmung :) Gruß, norro 14:09, 24. Apr. 2007 (CEST)

text: Bei einem Thema, das eigentlich schon seit langem als abgehakt betrachtet werden kann (der Bresenham-Algorithmus ist zufriedenstellend schnell) und um das sich nur eine Handvoll Forscher weiterhin kümmert, ist eine "Forschungsgeschichte" Overkill. Die ersten veröffentlichen Algorithmen gab es Anfang der 1960er, weil sich zu diesem Zeitpunkt die ersten Raster-Grafikgeräte (Plotter) durchsetzten. Ich möchte dazu nichts mehr ergänzen, aber falls es dich tröstet: ich werde in nächster Zeit einen umfassenden Artikel Geschichte der Computergrafik anlegen. --Phrood 21:55, 24. Apr. 2007 (CEST)
thread_title:  Exzellenzkandidatur April 07 

message: Mir ist ein Auslassungsfehler aufgefallen, und zwar die Problematik der Winkel zwischen zwei sich kreuzenden gerasterten Linien. Donald Knuth: A note on digitized angles. Electronic Publishing — Origination, Dissemination, and Design 3 (1990), 99–104. --rtc 02:21, 11. Mai 2007 (CEST)
replies: text: Das Paper ist mir bekannt. Es geht da aber um Pfeile und allgemeiner um Polylinien, das Problem ist daher besser bei Rastern von Polygonen aufgehoben --Phrood 09:04, 11. Mai 2007 (CEST)
replies: text: Eigentlich ist es ein recht allgemeines Problem auch bei Linien, und zwar wenn man die Rasterisierung von zwei sich kreuzenden Linien bei gleichbleibendem Winkel in Abhängigkeit von den Koordinaten des Punkts betrachtet, in dem sie sich kreuzen. Obwohl der Winkel immer der gleiche ist, variiert dabei die Rasterisierung um den Kreuzungspunkt herum, und zwar "When a line of slope a/b meets a line of slope c/d at a point (x_0, y_0), the number of different digital shapes it can  produce as (x_0, y_0) varies is |ad-bc|. Moreover, each of these shapes is equally likely to occur, if (x_0, y_0) is chosen uniformly in the plane." --rtc 09:42, 11. Mai 2007 (CEST)
thread_title:  Auslassungsfehler 

message: Spielt die Linienbreite eine Rolle? Spielt die Form eine Rolle? Was ist eine Linie im Sinne des Rasterns von Linien? Eine ideale Strecke hat die Breite Null und eine vorgegebene Länge. Sie ist gerade. Man kann keine ideale Strecke zeichnen. Je feiner die Auflösung von Displays wird, desto dünner wird eine "ideale Strecke" angenähert. Ist das so gemeint?  --Hutschi 11:00, 11. Mai 2007 (CEST)
replies: text: Ja; die Rasterung von Linien geht immer von einer Einheitsgröße von einem Pixel aus. Der Artikel beschreibt das ja sehr gut. Die Einbeziehung einer Linienbreite oder Linienform wäre die Rasterisierung von Pinselstrichen entlang von Linien, nicht mehr die von Linien an sich. --rtc 12:08, 11. Mai 2007 (CEST)
thread_title: Linienbreite, Linienform

message: Natürlich ein guter, interessanter Artikel.
Was mich etwas irritiert ist die Unterscheidung von Linien und Kurven (oder Graphen?). Ist eine Linie immer gerade?--Kölscher Pitter 20:07, 11. Mai 2007 (CEST)
replies: text: Im Jargon, ja. --rtc 22:56, 11. Mai 2007 (CEST)
thread_title: Linie - Gerade

message: Vielleicht sollte ein Phänomen des AntiAlias erwähnt werden: Auf aktuellen Computern wird zumeist mit einem Gamma-Wert von 2.2 (Windows) oder ich glaube 1.8 (Mac) gearbeitet. Fast alle AntiAliasing-Vorkommnisse gehen allerdings von Gamma =1.0 aus. Wieso ist das so? 
Ein Test dazu: http://www.hirnsohle.de/pics/antialiasTest.png
Ich muss allerdings zugeben dass ich beim herumtreiben an fremden Computern i.d.R. sehr "idividuelle" Displayeinstellungen und damit Gamma-Werte vorfand.
:Dass Gammakorrektur berücksichtigt werden muss, ist wohlbekannt, wird aber von vielen Implementierungen ignoriert (aus Performancegründen, Unwissen oder Gründen der Einfachheit). Das sollte jedoch im Artikel Antialiasing erwähnt werden. --Phrood 00:14, 12. Mai 2007 (CEST)
thread_title:  Antialias vs Gamma 

message: Warum wird dieses nicht angezeigt?--Kölscher Pitter 17:24, 15. Sep. 2007 (CEST)
replies: text: Das Problem gibt es z.Z. auch bei anderen kleinen Bildchen, siehe WP:FZW --Phrood 17:29, 15. Sep. 2007 (CEST)
replies: text: Bei mir sehe ich es. Aber heute scheint irgendwas auf dem WP-Server faul zu sein, ich sehe diverse andere Bilder in Artikeln nicht. Da muss wohl einer mal ein paar Leitungen mit einem Pümpel durchblasen... --PeterFrankfurt 23:39, 15. Sep. 2007 (CEST)
thread_title:  Excellentsymbol 

message: Es gibt doch auch Algorithmen, die fuer das Rastern von Linien mit einer Dicke >1 Pixel optimiert sind, inkl. den Linien-Enden (flach, spitz, rund usw.), wahlweise wieder mit Antialiasing. Kann dazu nicht noch mal jemand hinzufuegen? :-) --RokerHRO 14:52, 17. Okt. 2008 (CEST)
replies: text: Ohne Antialiasing: Rasterung (Computergrafik)#Rasterung dicker Primitiven. Für hochwertiges Antialiasing dicker Kurven siehe z.B. , das würde aber den Rahmen des Artikels sicher sprengen. --Phrood 21:09, 17. Okt. 2008 (CEST)
replies: text: Das angegebene PDF-Dokument kann leider nicht frei heruntergeladen werden. :-( Hast du noch andere Quellen? Es ist ja auch nicht Aufgabe der Wikipedia, solche Themen in aller Ausführlichkeit zu behandeln, aber die Grundprinzipien sollten doch schon erklärt werden, finde ich. --RokerHRO 22:45, 17. Okt. 2008 (CEST)
replies: text: Unter Antialiasing (Computergrafik)#Prefiltering und Flächenabtastung sind noch weitere Arbeiten verlinkt. Das verwendete Antialiasing-Prinzip nennt sich Prefiltering und wird dort erklärt, die Methoden unterscheiden sich hauptsächlich in der Effizienz der Berechnung. --Phrood 23:46, 17. Okt. 2008 (CEST)
thread_title:  Algorithmen fuer "dicke" Linien? 

message: Laut Artikel lautet die Formel für d: f(x,y) = ax + by + c = 0
Dies kann definitiv nicht der Fall sein: Beispiel Gerade durch den Ursprung im 45° Winkel:
f(1,1) = 1 \cdot 1 + 1 \cdot 1 + 0 = 2
Zudem ist diese schreibweise sehr verwirrend. Eine allgemeine Form der Geradengleichung:
y = mx + b
Umstellen nach 0:
0 = mx + b -y \Rightarrow F(x,y) = mx + b - y  = 0
Habe dies überprüft, im 45° Winkel ist m = 1 und da durch den Ursprung b = 0:
F(1,1) = 1 \cdot 1 + 0 - 1 = 0 Und in der Tat der Punkt liegt auf der Geraden. (nicht signierter Beitrag von 88.68.183.29 (Diskussion) 20:38, 19. Feb. 2014 (CET)
thread_title:  Fehler in der Funktion zur berechnung für O und NO 

message: – GiftBot (Diskussion) 22:17, 3. Jan. 2016 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekte Weblinks