Diskussion:Rasterung von Linien

Dieser Artikel war am 11. Mai 2007 der Artikel des Tages.

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

"Probleme"

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)

Dieser Artikel ist keine Diplomarbeit, sondern Vulgarisierung. Selbst Foley verwendet als Überschrift "Additional Issues". Besserer Vorschlag? --Phrood 00:50, 10. Mär. 2007 (CET)

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)

Formeln Delta-O und Delta-NO

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)

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)

Review Schreibwettbewerb März 2007

nominiert von Phrood

bislang nur überscrollt, aber ich (als extrem blutiger Laie) habe zwei Probleme mit dem Artikel:

# das Lemma ist irgendwie unglücklich, da es in dem Artikel ja nicht um das Lemma "Rasterung" sondern um "Rasterung einer Linie" geht. Klammerlemmata sollten imho eingesetzt werden, wenn ein Begriff in verschiedenen Ausprägungen genutzt wird. Wie wäre es bsp. mit Linienrasterung?

# der Artikel tendiert extrem in die Richtung eines how-to auf extrem hohem Niveau, vor allem, da die verschiedenen Techniken der Linienrasterung detailliert beschrieben und damit in den Vordergrund gestellt werden.

Gruß -- Achim Raschka 10:16, 2. Mär. 2007 (CET)

Danke für das Feedback.

Zu 1) Sehe ich ein. Es ist aber nicht so einfach, ein deutsches Lemma zu wählen. Linienrasterung wird laut Google nicht sehr oft verwendet, und Rasterung von Linien klingt auch nicht so elegant. Mal sehen...

Zu 2) Bitte präzisieren. Handelt es um die Sprache oder den Inhalt des Artikels? Falls es um letzteres geht, welchem Aspekt sollte man deiner Meinung nach mehr Raum geben? --Phrood 11:28, 2. Mär. 2007 (CET)

Ich bin als CAD-ler und Fotomensch etwas vorbelastet, finde den Artikel sehr gut. Die Einleitung besteht in meinen Augen gut den Oma-Test, da bin ich aber vielleicht auch zusehr Fachidiot. Allerdings würde ich mal sagen, daß das nicht allein 2D betriff, in 3D besteht das gleiche Problem (Rendern z.B.). Gut gemacht, gut belegt - kann man eigentlich schon wissenschaftlich nennen. --RalfR 20:41, 3. Mär. 2007 (CET)

Von mir vor allem Lob für eine sehr anschauliche Darstellung mit exzellenten Illustrationen, außerdem ist die breite Auswahl der angesprochenen Verfahren und ihre Belegung durch Quellen vorbildlich. Ein paar kleine ergänzende Wünsche hatte ich schon in der dortigen Diskussion geäußert. --PeterFrankfurt 01:45, 8. Mär. 2007 (CET)

Schöner Artikel, mit schönen Grafiken! Er gibt das gute Gefühl, hier nachlesen zu können, wenn man selbst eine Linie auf einem Raster darstellen muss. Anmerkungen:

• Die Einleitung ist nicht selbsterklärend. Ich bin mir nicht sicher, ob die Problematik der Rasterung deutlich wird, ohne den Querverweisen folgen zu müssen.
• Zweifarbige Linien -> Einfarbige Linien (oder besser, wie auch unten im Text: Linie + Hintergrund)
• Abschnitt Verallgemeinerung auf beliebige Richtungen ist nicht notwendig, da einleuchtend (auch die Gradengleichung wird m.E. zu ausführlich behandelt; sicherlich gibt es dazu einen Wikilink, so dass das Ergebnis genügte).
• 4-connected, 8-connected, hexagonale Raster etc: leider habe ich dazu keinen Wikilink gefunden. Vielleicht wird eines Tages der Artikel Morphologische Bildverarbeitung ausgebaut.

Anton 22:06, 9. Mär. 2007 (CET)

Die Einleitung finde ich klar genug, Verbesserungsvorschläge wären natürlich willkommen. Den Abschnitt zur Verallgemeinerung auf beliebige Richtungen halte ich für unabdigbar, da die Änderungen am Algorithmus nicht trivial sind. Ich bin mir nicht sicher, was du bei der Geradengleichung kürzen würdest, aber sie kann durchaus detailliert dargestellt werden, da auch folgende Abschnitte auf die Steigung m Bezug nehmen. Zur connectedness gibt es offenbar keinen Artikel, ich weiß nicht mal, ob es eine deutsche Übersetzung des Begriffs gibt. Bildverarbeitung hat a priori nichts mit der Computergrafik zu tun. --Phrood 22:58, 9. Mär. 2007 (CET)

Wie wäre es für die Einleitung mit:

Das Rastern von Linien ist ein Spezialfall der Rasterung (Computergrafik), mit dem Ziel, eine kontinuierliche Linie auf einem Grafikgerät mit diskreten Bildpunkten darzustellen. Dabei wird eine durch Anfangs- und Endpunkt definierte Strecke durch eine Rastergrafik angenähert.

Grundlegende Verfahren rastern Linien einfarbig (monochrom), eine bessere Darstellung ergibt sich mit fortgeschrittenen Verfahren mit mehr Farbabstufungen und Kantenglättung (Antialiasing). Höher entwickelte Techniken berücksichtigen auch die Breite der Linie (Linienstärke) oder zeichnen eine Linie, indem sie einen imaginären Pinsel an ihr entlang bewegen.

Da in der Computergrafik auch komplexere geometrische Figuren wie Polygone und Kurven häufig aus Liniensegmenten zusammengesetzt werden, bildet das Rastern von Linien gleichzeitig die Ausgangsbasis für das Rastern von Polygonen und das Rastern von Kurven. Von besonderem Interesse ist das Rastern von Linien bei der Darstellung von Drahtgittermodellen.

Der Abschnitt zur Verallgemeinerung ist in der Tat unabdingbar. --Bitbert 14:09, 13. Mär. 2007 (CET)

Ich habe die Einleitung etwas umformuliert, ist sie so besser? Komplizierte Begriffe wie kontinuierlich und diskret sollten vielleicht lieber vermieden werden. Die Linienstärken habe ich auch nicht erwähnt, da sie vor allem (soweit sie sich auch auf andere Kurven beziehen) im Artikel Rasterung (Computergrafik) beschrieben werden. --Phrood 21:33, 13. Mär. 2007 (CET)

Ist besser, aber ich finde die Verlinkung nach wie vor unglücklich: An erster Stelle wird auf den zwar richtigen aber zu allgemeinen Artikel Computergrafik verwiesen, der deutlich aufschlussreichere Überblicksartikel Rasterung (Computergrafik) ist erst viel weiter hinten in einer Klammer und unter falschem Namen versteckt. Algorithmus würde ich hier überhaupt nicht anlinken, „Verfahren“, „Methode“ oder „Technik“ ist allgemeinverständlicher und an dieser Stelle genau so gut. Hinter „Polygon“ und „Kurve“ hätte ich ohne den Quelltext niemals Rasterung von Polygonen und Rasterung von Kurven vermutet; ich würde beide Artikel mit ihrem tatsächlichen Namen ansprechen. --Bitbert 14:21, 22. Mär. 2007 (CET)

Auf Computergrafik sollte verwiesen werden, damit auch eine P.o.m.A. weiß, um welches Fachgebiet es überhaupt geht. Algorithmus ist ein so fundamentaler Begriff, dass der Artikel kaum ohne ihn auskommt, daher kann er auch gleich in der Einleitung verlinkt werden. Die Links zu den anderen Raster-Primitiven habe ich entfernt, da sie sowieso nicht besonders interessant sind. --Phrood 15:48, 31. Mär. 2007 (CEST)

Exzellenzkandidatur April 07

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)

•  Pro Der Artikel beeindruckt mich als Laien. Er macht einen sehr guten Eindruck. Für mich exzellent. Julius1990 18:06, 22. Apr. 2007 (CEST) PS: Der Kandidatenbaustein fehlt noch im Artikel.
• pro Der Arbeit beeindruckt durch seine didaktisch gute Aufbereitung. Als völliger Informatik-Laie habe ich immerhin verstanden, worum es geht und wieso das wichtig ist. -- 80.139.122.183 18:28, 22. Apr. 2007 (CEST)
•  Pro Exzellenter, leicht verständlicher Artikel mit ebenso exzellenten Darstellungen, also muss hier auch ein Exzellenz-Baustein rein ;) -- tw86 ^{Lächle mal wieder :)} 21:27, 22. Apr. 2007 (CEST)
•  Pro, sehr faszinierend --Pitichinaccio 22:45, 22. Apr. 2007 (CEST)
• Wow, ein toller Artikel. Ich habe ihn gerne und mit sehr viel Interesse und Freude gelesen. Die vielen nützlichen Grafiken im Artikel machen daraus eine sehr verständliche Thematik. Bevor ich euphorisch meine Zustimmung verkünde, hier einige Punkte, die mir dennoch aufgefallen sind:
  1. Abschnitt "Bresenham-Algorithmus": „Um die Position von M gegenüber der Linie zu bestimmen, wird eine andere Form der Geradengleichung verwendet“. Das liest sich irgendwie merkwürdig. Also warum nicht die Form der Geradengleichung konkret benennen? (Ein tollkühner Versuch von mir: Koordinatenform?)
  2. Abschnitt "Bidirektionale Rasterung": „Um die Geschwindigkeit der Rasterung weiter zu erhöhen, liegt es nahe, die Linie bidirektional, also gleichzeitig vom Anfangs- und vom Endpunkt [...] zu zeichnen“. Diese Überlegung liegt mir leider nicht so nahe, wie der Satz suggeriert. Mir ist immernoch nicht ganz klar, woher dort der Geschwindigkeitsvorteil kommt. Hier würde ich mir noch einen Satz wünschen, der diesen Zusammenhang klarmacht.
  3. Im Abschnitt „Eigenschaften und Vergleich“ schlage ich − sofern sinnhaft machbar − eine Tabelle vor, die die einzelnen Verfahren hinsichtlich benötigter Rechenoperationen bzw. Geschwindigkeit gegenüberstellt.

  Gruß, --norro 23:47, 22. Apr. 2007 (CEST)

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)

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)

• Pro. War von der Jury der Sektion auch als ein Kandidat für den Gesamtsieg nominiert, an diesem Artikel gibt es imho nichts zu meckern. --Uwe G. ¿⇔? 00:54, 23. Apr. 2007 (CEST)
• Pro, aus meiner (Dreiviertellaien-)Sicht perfekt: ein sehr informativer Artikel, dessen Lektüre gut zumutbar ist und auch noch Spaß macht. JHeuser 19:36, 23. Apr. 2007 (CEST)
• Pro - interessanter und guter Artikel, allerdings durchaus noch mit Verbesserungsmöglichkeiten ;-)
  Was mich speziell interessieren würde - obwohl das ganze Gebiet noch sehr jung ist -, wäre eine "historische Entwicklung" : Evtl. eine Art Timeline, wann welche Weiterentwicklung kam - evtl. auch (falls möglich) mit einer entsprechenden Begründung, warum gerade zu dem Zeitpunkt (Hintergrund ist das vermutlich damit eng verknüpfte Gebiet der Anwendung bzw. Hard- und Softwareentwicklung - z.B. CAD, Computergraphik, etc.). Derzeit werden eigentlich nur die allerersten Entwicklungen in den 60ern zeitlich eingeordnet. -- srb ^♋ 21:32, 24. Apr. 2007 (CEST)

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)

•  Pro, mir fällt dazu nur ein Wort ein: phantastisch! Verständlich, ausführlich und interessant - und das alles zu einem Thema, dem man eigentlich kein solches Ergebnis (als Artikel) zutraut! --Cvf-ps^Disk_+/- 18:46, 25. Apr. 2007 (CEST)

• pro wirklich ein super Artikel. Er erklärt prägnant und allgemeinverständlich, worum es geht und wozu das Ganze gut ist. Die Gliederung ist simpel aber logisch vom Einfach zum Komplexen, wobei allerdings nie so sehr ins Detail gegangen wird, dass der Artikel überfrachtet wäre. Die Grafiken tragen ganz erheblich zum Verständnis der jeweiligen Problemstellung bei, an sich ist aber auch der Text sehr laientauglich. Man merkt hier ganz einfach, das Text und Illustrationen aus einem Guss sind. Für mich als ITler war die Lektüre eine Freude, der Artikel wäre auch ein würdiger Kandidat auf den Gesamtsieg beim SW gewesen.--Wiggum 20:54, 2. Mai 2007 (CEST)

• pro Ganz klar (sorry für das späte Votum, ist mir irgendwie durchgeflutscht ...). Damit wären dann die 10 voll ;) Denis Barthel 01:27, 3. Mai 2007 (CEST)

•  Pro, mich beeindruckt vor allem die gute Illustrierung, die einige Zusammenhänge erst richtig offenlegt. Außerdem finde ich keine Lücke in der Abdeckung aller relevanter Verfahren. --PeterFrankfurt 01:48, 3. Mai 2007 (CEST)

Auslassungsfehler

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)

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)

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)

Hints

Da beim Rastern von Linien Kompromisse gemacht werden müssen, kann dem Rasterungsalgorithmus eine Vorgabe gemacht werden, zum Beispiel in Form von Hints. Hierdurch wird eine bessere Näherung erreicht, wenn zum Beispiel mehrere Linien nebeneinander gezeichnet werden sollen und der Abstand eine Rolle spielt, wie zum Beispiel bei Schriftzeichen. Sollte man einen Hinweis einfügen? --Hutschi 08:24, 11. Mai 2007 (CEST)

Hints haben eher wenig mit dem Rastern von Linien zu tun. Hints verschieben hauptsächlich die Knoten- und Kontrollpunkte von zu füllenden geschlossenen Splinepfaden (die der Außenlinie der Zeichen entsprechen). --rtc 08:35, 11. Mai 2007 (CEST)

Wie wird dann folgender Fall betrachtet: Ich habe mehrere parallele Linien, die gleichen Abstand untereinander haben. Durch das Rastern wird der Abstand aber unterschiedlich. Das wird von den angegebenen Algorithmen ignoriert. (Es wäre zum Beispiel eine Verschiebung um ein Raster erforderlich, um eine bessere Darstellung zu erreichen, wenn man Wert auf gleichen Abstand legt.)

Beispiel (Prinzip):

***********************************
***********************************

***********************************

wäre zu rastern als:

***********************************

***********************************

***********************************

Gibt es auch den Fall der zufälligen Fehlerverteilung zur Rasterung, um eine optisch bessere Näherung zu erreichen? Dabei wird die Wahrscheinlichkeit mit betrachtet, mit der ein Punkt auf die Linie fällt. Ich gebe nur das Prinzip an, in der Vergrößerungsstufe sieht es nicht gut aus.

Beispiel:

**********-**---*------------------
----------*--***-******************* 

--Hutschi 09:36, 11. Mai 2007 (CEST)

Das ist mir schon bewusst, nur ist Hinting eine Sache der Knoten- und Kontrollpunkte (hier: Endpunkt der Linie), nicht der Linienrasterisierung selbst. Dazu glaube ich nicht, dass Hinting je für Rasterisierung reiner Linien umgesetzt wurde. Es wird wie gesagt normalerweise eingesetzt zur Platzierung von Knotenpunkten auf der Außenlinie der Buchstaben bei Fonts. Diese werden gefüllt, nicht nachgezeichnet. Die Fehlerverteilung dürfte ganz einfach durch die Kombination eines Antialiasing-algorithmus mit einem Ditheringalgorithmus realsierbar sein. Ich vermute, es das Ergebnis ist bei Bildschirmtypischen Auflösungen optisch deutlich unbefriedigender als ohne; erst recht bei Druck, weil die Farbpunkte sowieso ineinanderlaufen. Das sieht dann aus als hätte der Drucker mist gemacht und die Farbe würde ausfransen.--rtc 09:53, 11. Mai 2007 (CEST)

Danke. Offensichtlich ist "Hint" das falsche Wort. Ich meine "Verbesserung der Darstellung durch zusätzliche Angaben". Wahrscheinlich wird das also nicht für die Linienrasterung verwendet. Wird Dithering bei der Rasterung verwendet? --Hutschi 10:22, 11. Mai 2007 (CEST)

Nun, eine Verbesserung der Linienrasterisierung wird ja durch ein solches Hinting nicht erreicht, sondern nur die Verbesserung der Darstellung der Gesamtzeichnung bei niedrigen Auflösungen. Tatsächlich sind Fonts, soweit ich sehen kann, der einzige Anwendungsfall, wo Hinting wirklich Sinn macht, denn Zeichen sind gerade komplex genug, um bei niedrigen Auflösungen überhaupt solche Darstellungsprobleme auszulösen, umgekehrt noch einfach genug, um sinnvoll bei dieser niedrigen Auflösung dargestellt werden zu können. Die existierenden Hinting-Verfahren bieten auch nur (vergleichsweise) sehr primitive Möglichkeiten und sind ziemlich auf genau diesen Anwendungsfall zugeschnitten; die am häufigsten verwendeten Hint-Arten lösen z.B. einfach nur die Aufgabe, im Bereich von ein und zwei Pixeln dafür zu sorgen, dass vertikale und horizontale Stems der gleichen Breite/Höhe mit dem jeweils gleichen Pixelabstand gefüllt werden. Auch will man möglichst bei einem 'm', dass der Pixelabstand zwischen den drei vertikalen Stems gleich ist, aber da hört es beim ursprünglichen Type1-Standard auch schon auf – keine Möglichkeit für mehr als zwei solcher Paare. (Ok, TrueType hints können schon sehr weit ausgereizt werden, bis hin dazu, dass man die Ornamente bei Initialen-Fonts bei niedrigen Aufklösungen verschwinden lassen kann, aber das ist nicht der normale Anwendungsfall.) Bei Illustrationen gibt es keine solchen kritischen Abstände, bzw. würde niemand ein solches zeitaufwändiges Hinting machen, nur damit die Illustration in Thumbnail-Größe auch gut aussieht – das ist einfach kein Anwendungsfall. Die Sicherstellung allgemein von gleichen Abständen oder sonstigen Relationen bei Elementen von Illustrationen (nicht in der Rasterisierung, sondern in der eigentlichen Zeichnung) ist der Standardanwendungsfall von Metapost. Dithering wird meines Wissens aus den genannten Gründen bei Linienrasterung nicht eingesetzt: Es verschlechtert den optischen Eindruck sowohl bei Bildschirmdarstellung als auch bei Druck gravierend, statt ihn zu verbessern. Probier's ruhig aus. Es sieht nach dem schlechten Scan einer s/w-Vorlage (Bildschirm) bzw. nach Tinte-Ausfransungs-Problemen (Druck) aus. --rtc 12:02, 11. Mai 2007 (CEST)

Linienbreite, Linienform

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)

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)

Linie - Gerade

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)

Im Jargon, ja. --rtc 22:56, 11. Mai 2007 (CEST)

Antialias vs Gamma

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)

Frühe Algorithmen

Ein weiterer früher Linienrasterungs-Algorithmus stammt von Stockton und nennt sich XYmove plotting. Er wurde im April 1963 veröffentlicht. (Bresenham entwickelte seinen Algorithmus nach eigenen Angaben im Sommer 1962, präsentierte ihn aber erst im August 1963.) Danielssons Algorithmus wurde ebenfalls 1963 veröffentlicht. Vielleicht kann jemand erklären, wie Stocktons Algorithmus funktioniert - ich habe ihn jedenfalls überhaupt nicht verstanden. Optimal im Bresenham-Sinn sind die mit ihm gezeichneten Linien jedenfalls nicht. --Phrood 03:36, 12. Sep. 2007 (CEST)

Hmm, da kommt man ja ohne Account nicht ran. Gibt es da irgendeine Kurzfassung oder eine frei zugängliche Version irgendwo? Interessant finde ich sowas immer. --PeterFrankfurt 14:50, 12. Sep. 2007 (CEST)

@PeterFrankfurt: Du hast Post. Grüße, --CyRoXX ^(? ±) 16:34, 12. Sep. 2007 (CEST)

Danke, angekommen. Das ist ja wirklich verwirrend, aber hochinteressant. Vor allem, wie da anscheinend in einem Aufwasch alle Himmelsrichtungen auf einmal abegdeckt werden, wo man sonst immer nur einen einzelnen Oktanten betrachtet. --PeterFrankfurt 16:52, 12. Sep. 2007 (CEST)

Hier mal eine Umsetzung in QBASIC mit handgestrickten Beispieldaten. Diese behandeln den Fall dx>0, dy=1, also nur 1 y-Schritt während der ganzen Linie. Natürlich etwas umformatiert und umformuliert. Da kann man die verschiedenen Variablen verfolgen:

 ' procedure Stockton_xymove(XZ, YZ, XN, YN);
 ' value   XZ, YZ, XN, YN;
 ' integer XZ, YZ, XN, YN;
 ' comment xymove computes the code string required to move the
 '   pen of a digital incremental X,Y-plotter from an initial point
 '   (XZ, YZ) to a terminal point (XN, YN) by the "best" approximation
 '   to the straight line between the points. The permitted
 '   elemental pen movement is to adjacent point in a plane
 '   Cartesian point lattice, diagonal moves permitted. The eight
 '   permitted pen movements are coded
 '      1 = +Y, 2 = +X+Y, 3 = +X, 4 = +X-Y,                               die 8 Bewegungsrichtungen im Uhrzeigersinn
 '      5 = -Y, 6 = -X-Y, 7 = -X, 8 = -X+Y.
 '   The approximation is "best" in the sense that each point traversed
 '   is at least as near the true line as the other candidate
 '   point for the same move.
 '   xymove does not use multiplication or division.;
 ' begin
 '   integer A, B, D, E, F, T, I, move;
 '   comment code(J) is a procedure which returns a value of code
 '     according to the following table:
 '          J  1 2  3 4  5 6  7 8  9 10  11 12  13 14  15 16              Spaeter in der inneren Schleife wird immer ein
 '       code  1 2  3 2  3 4  5 4  5  6   7  6   7  8   1  8              Grundcode (immer gerade, also diagonal) oder
 '                                                                        Grundcode-1 (ungerade, achsenparallel) gesendet.
 '                                                                        Fuer jeden Oktanten ein Zahlenpaar aus
 '                                                                        Richtungscode und Richtungscode+-1.
 DIM code%(16)
 code%(1) = 1: code%(2) = 2: code%(3) = 3: code%(4) = 2
 code%(5) = 3: code%(6) = 4: code%(7) = 5: code%(8) = 4
 code%(9) = 5: code%(10) = 6: code%(11) = 7: code%(12) = 6
 code%(13) = 7: code%(14) = 8: code%(15) = 1: code%(16) = 8
 '     plot(move) is a procedure which sends move to the plotter as a
 '     plotter command.; 
 
 XZ = 0: YZ = 0: XN = 7: YN = 1 ' Beispieldaten, dy=1 als Test
 
   IF XZ = XN AND YZ = YN THEN GOTO return1
   A = XN - XZ: B = YN - YZ
   D = A + B
   T = B - A
   I = 0
   IF B >= 0 THEN I = 2
   IF D >= 0 THEN I = I + 2
   IF T >= 0 THEN I = I + 2
   IF A >= 0 THEN I = 8 - I ELSE I = I + 10                           ' I ist diagonale Grundrichtung, I-1 achsenparallele
   A = ABS(A): B = ABS(B)
   F = A + B                                                          ' F ist Gesamtschrittzahl
   D = B - A                                                          ' D zeigt an, ob x (<0) oder y (>0) schnelle Richtung ist
   IF D >= 0 THEN
     T = A: D = -D
           ELSE
     T = B
     END IF                                                           ' D=-abs(abs(dx)-abs(dy)); T=min(abs(dx),abs(dy))
   E = 0
 PRINT "A; B; D; E; F; T; move " ' Ueberschrift drucken
 repeat1:                                                             ' In Schleife D und T fest, F Schrittzaehler
     A = D + E: B = T + E + A                                         ' B aehnelt Bresenham-Fehlerglied
     IF B >= 0 THEN
       E = A: move = code%(I): F = F - 2                              ' Diagonalschritt, zaehlt als 2 Schritte
             ELSE
       E = E + T: move = code%(I - 1): F = F - 1                      ' achsenparalleler Schritt, 1 Schritt
       END IF
     PRINT A; B; D; E; F; T; move ' plot(move);                       ' drucken statt plotten
     IF F > 0 THEN GOTO repeat1
 return1:
 END
 
 ' Beispiellauf:
 ' A; B; D; E; F; T; mov      E=0=Eo, D=-6, T=1 fest
 ' -6 -5 -6  1  7  1  3       A=                  D+Eo    =-6; B=T+E+A=T+Eo+D+Eo=                 T+2*Eo+  D= -5; Par: E=                  Eo+  T= 1
 ' -5 -3 -6  2  6  1  3       A=D+En=             D+Eo+  T=-5; B=T+En+An=T+Eo+T+D+Eo+T=         3*T+2*Eo+  D= -3; Par: E=E+T=              Eo+2*T= 2
 ' -4 -1 -6  3  5  1  3       A=D+En=             D+Eo+2*T=-4; B=T+En+An=T+Eo+2*T+D+Eo+2*T=     5*T+2*Eo+  D= -1; Par: E=E+T=              Eo+3*T= 3
 ' -3  1 -6 -3  3  1  2       A=D+En=             D+Eo+3*T=-3; B=T+En+An=T+Eo+3*T+D+Eo+3*T=     7*T+2*Eo+  D=  1; Dia: E=An=             D+Eo+3*T=-3
 ' -9 -11 -6 -2  2  1  3      A=D+En=D+D+Eo+3*T=2*D+Eo+3*T=-9; B=T+En+An=T+D+Eo+3*T+2*D+Eo+3*T= 7*T+2*Eo+3*D=-11; Par: E=En+T=D+Eo+3*T+T=D+Eo+4*T=-2
 ' -8 -9 -6 -1  1  1  3       A=D+En=D+D+Eo+4*T=2*D+Eo+4*T=-8; B=T+En+An=T+D+Eo+4*T+2*D+Eo+4*T= 9*T+2*Eo+3*D= -9; Par: E=En+T=D+Eo+4*T+T=D+Eo+5*T=-1
 ' -7 -7 -6  0  0  1  3       A=D+En=D+D+Eo+5*T=2*D+Eo+5*T=-7; B=T+En+An=T+D+Eo+5*T+2*D+Eo+5*T=11*T+2*Eo+3*D= -7; Par: E=En+T=D+Eo+5*T+T=D+Eo+6*T= 0

 ' Bei mir ist Obiges nicht richtig darstellbar, deshalb hier bis auf das jweilige Endergebnis gekürzt:
 
 ' Beispiellauf:
 ' A; B; D; E; F; T; mov      E=0=Eo, D=-6, T=1 fest
 ' -6 -5 -6  1  7  1  3       A=  D+Eo    =-6; B=   T+2*Eo+  D= -5; Par: E=  Eo+  T= 1
 ' -5 -3 -6  2  6  1  3       A=  D+Eo+  T=-5; B= 3*T+2*Eo+  D= -3; Par: E=  Eo+2*T= 2
 ' -4 -1 -6  3  5  1  3       A=  D+Eo+2*T=-4; B= 5*T+2*Eo+  D= -1; Par: E=  Eo+3*T= 3
 ' -3  1 -6 -3  3  1  2       A=  D+Eo+3*T=-3; B= 7*T+2*Eo+  D=  1; Dia: E=D+Eo+3*T=-3
 ' -9 -11 -6 -2  2  1  3      A=2*D+Eo+3*T=-9; B= 7*T+2*Eo+3*D=-11; Par: E=D+Eo+4*T=-2
 ' -8 -9 -6 -1  1  1  3       A=2*D+Eo+4*T=-8; B= 9*T+2*Eo+3*D= -9; Par: E=D+Eo+5*T=-1
 ' -7 -7 -6  0  0  1  3       A=2*D+Eo+5*T=-7; B=11*T+2*Eo+3*D= -7; Par: E=D+Eo+6*T= 0

Die Rollen der Variablen A, B und E ist mir noch nicht ganz klar. 'move' macht jedenfalls die richtigen Wege: meistens horizontal und einmal diagonal aufwärts.

 ' Beispiellauf mit YN=6, also dy=dx-1, also immer Diagonalschritt (2), nur einmal Horizontalschritt (3)
 ' A; B; D; E; F; T; move
 ' -1  5 -1 -1  11  6  2
 ' -2  3 -1 -2  9  6  2
 ' -3  1 -1 -3  7  6  2
 ' -4 -1 -1  3  6  6  3
 '  2  11 -1  2  4  6  2
 '  1  9 -1  1  2  6  2
 '  0  7 -1  0  0  6  2

Uh, alles so bunt hier :-)...

Also was da mit den Variablen A, B und E passiert, ist mir immer noch nicht klar. Aber dieser Schrittzähler F ist unnötig kompliziert. Wenn man den in diesem IF D >= 0 THEN je nachdem auf A oder B setzt, bekommt man ihn als Schleifenzähler, kann ihn in der inneren Schleife aus dem IF herausnehmen und außerhalb einfach dekrementieren. Oder man wandelt diese repeat-Schleife gleich in eine normale FOR-Schleife um. Ich habe das hier auf meinem Rechner durch einen praktischen Versuch verifiziert. --PeterFrankfurt 21:19, 12. Sep. 2007 (CEST)

So, nun habe ich mal ein bisschen Mäuschen gespielt und einen der obigen Läufe mal zu Fuß nachgestellt und mir alle Zwischenschritte angesehen. Im Endeffekt läuft es auf den originalen Bresenham hinaus, aber von hinten durch die Brust ins Auge: Wo bei Bresenham bei einem Parallelschritt das (kleine) dy vom Fehlerterm abgezogen wird, ist es hier das mit 2 multiplizierte T (kuck an, der Faktor 2 wie bei Bresenham) vom B, wobei T praktisch identisch mit dy ist, nur anders ermittelt. Bei einem Diagonalschritt als Korrektur zum Fehlerglied nicht das (große) dx genommen, sondern das D, und das auch wieder verdoppelt. Das D ist zwar dx-dy, aber da beim Diagonalschritt der T-Schritt weggelassen wird, ist das wieder original wie bei Bresenham eine dx-Korrektur. Das A mit dem enthaltenen D-Term sorgt anscheinend für den Offset am Anfang, dass das Fehlerglied so initialisiert wird, dass der einzige andere Schritt wirklich in der Mitte der Linie erfolgt. Insgesamt also tatsächlich eine Identität zu Bresenham. Wild, wild, wild. --PeterFrankfurt 16:37, 15. Sep. 2007 (CEST)

Sowas interessiert mich, also habe ich noch etwas weiter damit herumgespielt. Was mich irritierte, war, dass hier gleich drei Variablen (A, B und E) gebraucht werden, wo Breseham mit einer einzigen für sein Fehlerglied auskam. Also habe ich versucht, die Variablen in der inneren Schleife ineinander einzusetzen. In einem ersten Schritt konnte ich das A loswerden. Dazu habe ich die obige Formulierung genommen und einfach die Zuweisung für A (nur eine Stelle im Text) in diejenigen Stellen eingesetzt, wo A vorkommt (auch nur zwei Stellen):

   E = 0
repeat1:                                                            ' In Schleife D und T fest, F Schrittzaehler
   B = T + E * 2 + D                                                ' B aehnelt Bresenham-Fehlerglied
   IF B >= 0 THEN
     E = E + D: move = code%(I): F = F - 2                          ' Diagonalschritt, zaehlt als 2 Schritte
           ELSE
     E = E + T: move = code%(I - 1): F = F - 1                      ' achsenparalleler Schritt, 1 Schritt
     END IF
   PRINT A; B; D; E; F; T; move ' plot(move);                       ' drucken statt plotten
   IF F > 0 THEN GOTO repeat1
return1:

In einem zweiten Schritt habe ich auch noch E eliminiert, so dass ähnlich wie bei Bresenham nur noch das B als Fehlerterm übrigbleibt:

   E = 0
   B = T + D
repeat1:                                                            ' In Schleife D und T fest, F Schrittzaehler
   IF B >= 0 THEN                                                   ' B aehnelt Bresenham-Fehlerglied
     B = B + 2 * D: move = code%(I): F = F - 2                      ' Diagonalschritt, zaehlt als 2 Schritte
           ELSE
     B = B + 2 * T: move = code%(I - 1): F = F - 1                  ' achsenparalleler Schritt, 1 Schritt
     END IF
   PRINT A; B; D; E; F; T; move ' plot(move);                       ' drucken statt plotten
   IF F > 0 THEN GOTO repeat1
return1:

Wenn man Letzteres ausprobiert, stellt man einen Versatz in der Ausgabe fest, dass die gleichen Zahlenwerte für B herauskommen wie in den Vorversionen, nur alles je eine Zeile früher. Das liegt daran, dass B in der alten Version direkt VOR der IF-Abfrage berechnet wird und hier erst danach, aber immer noch vor der PRINT-Anweisung für die Zwischenergebnisse. Die Ergebnisse sind ansonsten identisch zu denen davor. Warum Stockton diese Schritte nicht selbst gemacht hat, weiß ich nicht. - Wie oben bleibt es bei der Interpretation, dass das Bresenham in leicht anderer Formulierung ist. --PeterFrankfurt 16:29, 16. Sep. 2007 (CEST)

Abgesehen von obigen Details: Der Stockton hat mich auf eine vollkommen neue Idee gebracht, wie ich den Bresenham-Algorithmus viel eleganter als bisher auf alle 8 Oktanten ausdehnen kann, siehe in Kürze dort! --PeterFrankfurt 13:22, 13. Sep. 2007 (CEST)

Excellentsymbol

Warum wird dieses nicht angezeigt?--Kölscher Pitter 17:24, 15. Sep. 2007 (CEST)

Das Problem gibt es z.Z. auch bei anderen kleinen Bildchen, siehe WP:FZW --Phrood 17:29, 15. Sep. 2007 (CEST)

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)

Zufall

Gibt es Rasterungsverfahren, bei denen der Fehler nach einer Zufallsfunktion verteilt wird, um Treppeneffekte zu vermeiden? --Hutschi 17:23, 7. Mär. 2008 (CET)

Wie soll das gehen? Bei einfarbiger Rasterung gibt es immer Stufen. --Phrood 19:00, 7. Mär. 2008 (CET)

Es geht folgendermaßen: statt einer Stufe werden zufallsverteilt mehrere abwechselnde Punkte gesetzt, sodass nicht eine einzelne Stufe entsteht, sondern eine Art Miniaturraster. Das Bild erscheint dann eventuell wie leicht verrauscht. --Hutschi 20:30, 7. Mär. 2008 (CET)

Also unabsichtlich entstanden kenne ich sowas vom Scannen vergilbter Originale von Diagrammen oder von Faxen. Absichtlich könnte es vielleicht entstehen - und dann nach einem festen Algorithmus, also nur scheinbar zufällig - wenn man zwecks Anti-Aliasing /(und evtl. dicken Linien) zu einer Floyd-Steinberg-Ditherung greift, die macht gerne genau solche Effekte. --PeterFrankfurt 00:11, 8. Mär. 2008 (CET)

@Phrood: Dithering ist ein gutes Stichwort: Das sollte man noch erwähnen, und zwar bei Anti-Aliasing. Dort wird in der aktuellen Formulierung nur die Einfärbungsfarbe variiert. Per Dithering kommt man in dem Fall weiter, wenn man die Farbe nicht so fein wie gewünscht variieren kann. --PeterFrankfurt 00:14, 8. Mär. 2008 (CET)

Eine Beschreibung von Antialiasing durch Dithering ist mir nicht bekannt. Wenn ich eine Linie mit Antialiasing zeichne und das ganze mit Dithering in ein Binärbild umwandle, sieht es für meinen Geschmack noch schlimmer aus als die Linie ohne Antialiasing. --Phrood 03:15, 8. Mär. 2008 (CET)

Klar, da werfe ich jetzt zwei erstmal völlig unabhängige Mechanismen zusammen (nicht durcheinander). Dithering braucht man (nur) dann, wenn man ein Gerät mit nur sehr kleiner Farbauflösung hat, im Extremfall s/w, und will aber dieselben Effekte wie bei sauberem Antialiasing mit seinen Farbabstufungen erzielen. Wenn man sich das Ergebnis dann pixelweise ansieht, sieht es in der Tat schon mal grauenhaft aus, schlimmer als eine simple Treppe bei einem naiveren Algorithmus. Aus größerer Entfernung, wo das Auge die Chance zur Mittelwertbildung bekommt, wird es dagegen sehr viel organischer als die harte Treppe.

00000000000000000 00 0 0
       0 0 00 000000000000000000

oder so. Wie gesagt, s/w ist der Extremfall, mit ein paar mehr Farben (aber nicht 16 Mio, sagen wir 4096 wie beim Amiga, da habe ich das exzessiv programmiert), sieht es gleich viel sinnvoller aus. --PeterFrankfurt 22:03, 8. Mär. 2008 (CET)

Richtig, aber da müssen schon mehr als zwei verschiedene Farben dargestellt werden können. Wenn überhaupt, sollte die Technik im (z. Z. überarbeitungsbedürftigen) Artikel Antialiasing beschrieben werden. Aber vielleicht wird die Jungfrau Maria den Artikel demnächst sowieso überarbeiten. --Phrood 22:40, 8. Mär. 2008 (CET)

Ein Beispiel, wo es sinnvoll sein könnte, ist eine fast waagerechte Linie, die aber zwischen zwei Rastern liegt. Wie es aussieht, hängt von den Eigenschaften des Bildschirms ab. --Hutschi 12:45, 8. Mär. 2008 (CET)

PS: Ein Beispiel, wo es angewendet werden kann (und teilweise angewendet wird) ist der Schwarz-Weiß-Laserdrucker. Einige Laserdrucker verändern dann auch die Punktgröße - das ist aber ein anderes Prinzip. Auf Bildschirmen geht es wahrscheinlich kaum, aber bei Druckern wird es heute oft verwendet. Gesehen habe ich Zufallsrasterung aber vorrangig bei handdesignten Rasterschriften. Relativ gut sieht es aus, wenn eine Linie mit einer Linienbreite von 2 Pixeln gerastert wird. --Hutschi 10:40, 10. Mär. 2008 (CET)

Algorithmen fuer "dicke" Linien?

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)

Ohne Antialiasing: Rasterung (Computergrafik)#Rasterung dicker Primitiven. Für hochwertiges Antialiasing dicker Kurven siehe z.B. [1], das würde aber den Rahmen des Artikels sicher sprengen. --Phrood 21:09, 17. Okt. 2008 (CEST)

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)

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)

Bedeutung der Variablen

Es wäre echt toll wenn auch die "ungebildeten" Nicht-Mathematiker (wie ich) nachvollziehen könnten wofür die Variablen in den Formeln stehen, z.B. habe ich keine Ahnung was x0 oder y0 sind ? (nicht signierter Beitrag von 85.4.231.67 (Diskussion | Beiträge) 13:32, 31. Dez. 2009 (CET))

Wir reden hier von Linien. Die haben einen Anfangs- und einen Endpunkt. Die Koordinaten des Anfangspunkts nennt man je nach Geschmack mal (x0,y0), mal (x1,y1) oder mal (xa,ya), die des Endpunkts jeweils entsprechend (x1,y1), (x2,y2) oder (xe,ye). Leider ist das nicht stärker vereinheitlicht, und man muss notfalls aus dem Zusammenhang schließen, welche Variante gerade anliegt.

@Phrood: Im Kapitel Einfache Methoden geht das munter von Absatz zu Absatz durcheinander, das könnte mal vereinheitlicht werden. --PeterFrankfurt 19:36, 6. Jan. 2010 (CET)

Fehler in der Funktion zur berechnung für O und NO

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))

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://graphics.gmu.edu/raster/lines/
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Netzwerk-Fehler (7) andere Artikel, gleiche Domain
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://graphics.gmu.edu/raster/lines/
• http://www.it.jcu.edu.au/Research/topics/theses/phd/stephenson.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Netzwerk-Fehler (6) andere Artikel, gleiche Domain
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://www.it.jcu.edu.au/Research/topics/theses/phd/stephenson.html
• http://www.research.ibm.com/journal/sj/041/ibmsjIVRIC.pdf
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Problem mit Ressource (HTTP-Statuscode 403)
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://www.research.ibm.com/journal/sj/041/ibmsjIVRIC.pdf

– GiftBot (Diskussion) 22:17, 3. Jan. 2016 (CET)