Diskussion:Bresenham-Algorithmus

message: Der Algo. von Bresenham ist nicht zum rastern von Gradenstücken da, sondern zum Zeichnen von Linen mithilfe eines Plotters - er läßt sich nur auch für das Rastern von Geradenstücken verwenden - siehe: http://turing.fh-landshut.de/~jamann/bresenham.html
:die jetzige, allgemein gehaltene formulierung von wegen "fuer gerasterte ausgabe" ist doch ok, oder? -- seth 21:23, 27. Nov. 2006 (CET)
thread_title:  nicht rastern sondern eher plotten 

message: Ich hab mal versucht die kompakte variante zu implementieren, das gibt bei mir aber nur müll:
void line(int x0, int y0, int x1, int y1)
{
  int dx =  abs(x1-x0), sx = x0<x1 ? 1 : -1;
  int dy = -abs(y1-y0), sy = y0<y1 ? 1 : -1; 
  int err = dx+dy, e2; /* error value e_xy */
 
  for(;;){  /* loop */
    setPixel(x0,y0);
    if (x0==x1 && y0==y1) break;
    e2 = 2*err;
    if (e2 > dy) { err -= dy; x0 += sx; } /* e_xy+e_x > 0 */
    if (e2 < dx) { err += dx; y0 += sy; } /* e_xy+e_y < 0 */
  }
}
Die englische wikipedia hat eine sehr ähnliche kompakte variante:
 function line(x0, y0, x1, y1)
   dx := abs(x1-x0)
   dy := abs(y1-y0) 
   if x0 < x1 then sx := 1 else sx := -1
   if y0 < y1 then sy := 1 else sy := -1
   err := dx-dy
 
   loop
     setPixel(x0,y0)
     if x0 = x1 and y0 = y1 exit loop
     e2 := 2*err
     if e2 > -dy then 
       err := err - dy
       x0 := x0 + sx
     end if
     if e2 <  dx then 
       err := err + dx
       y0 := y0 + sy 
     end if
   end loop
Die scheint funktioniert bei mir. kann nochmal einer die kompakte hier überprüfen? 
Ich glaube da in der C variante hier das vorzeichen von dy umgedreht ist, müsste die korrekte variante
void line(int x0, int y0, int x1, int y1)
{
  int dx =  abs(x1-x0), sx = x0<x1 ? 1 : -1;
  int dy = -abs(y1-y0), sy = y0<y1 ? 1 : -1; 
  int err = dx+dy, e2; /* error value e_xy */
 
  for(;;){  /* loop */
    setPixel(x0,y0);
    if (x0==x1 && y0==y1) break;
    e2 = 2*err;
    if (e2 > dy) { err += dy; x0 += sx; } /* e_xy+e_x > 0 */
    if (e2 < dx) { err += dx; y0 += sy; } /* e_xy+e_y < 0 */
  }
}
sein (also err += dy anstatt -= dy) ... wenn jemand der gut ahnung hat einverstanden ist, dann kann er das ja vielleicht ändern. (nicht signierter Beitrag von 87.155.72.209 (Diskussion) 15:48, 3. Okt. 2011 (CEST)
replies: text: Ja, ich hatte zunächst übersehen, dass das dy ja schon als negativ initialisiert wird. Dann stimmt das jetzt so. --PeterFrankfurt 01:41, 5. Okt. 2011 (CEST)
thread_title:  kompakt fehler? 

message: Wie wär's mit Pseudocode? --PhilippW 18:39, 28. Jun 2004 (CEST)
replies: text: Wäre ich auf jeden Fall auch dafür. Und ein paar allgemeine Hinweise in Textform könnten für das grundlegende Verständnis sicher auch nicht schaden... Underdog 20:14, 28. Dez 2004 (CET)
thread_title:  code-beispiele 

message: Die Mathematik hinter dem Uralgorithmus sollte klarer herausgestellt werden. Die für mich entscheidende Idee, nämlich jene, die Gerade stets so zu interpretieren, dass ihre Steigung 0 <= m < 1 ist kommt nicht deutlich heraus. Die englische wiki ist hier viel verständlicher, dafür finden sich dort keine Übertragung auf den Kreis.
:Die Krux ist hier, dass das erste Programmbeispiel aus der älteren Artikelversion so elegant ist, dass die Beschränkung auf den ersten Oktanten wegfällt und alle Oktanten mit erfasst werden. Dadurch wird es relativ undurchschaubar. Ich habe dann, als ich später dazukam, genau deshalb noch die zweite, simplere Version hinterhergeschoben, die einfacher zu durchschauen ist und die ich im Einleitungsteil dazu auch halbwegs erklärt habe. Als Neuling damals habe ich es nicht gewagt, diese Version vor die bestehende zu stellen. Vielleicht sollte diese Umstellung doch mal stattfinden. --PeterFrankfurt 02:00, 20. Dez. 2006 (CET)
replies: text: Doch, das geht genau so. Die x2 und y2 sind die x- und y-Quadrate, wie sie in der Kreisgleichung x2+y2=r2 auftreten und für den Fehlerterm verwendet werden. Sie werden halt rekursiv berechnet, um nur shiften und nicht aufwendig multplizieren zu müssen. Und dies alles ist in den Absätzen direkt davor haarklein angekündigt und erläutert. --PeterFrankfurt 02:00, 20. Dez. 2006 (CET)

text: Nein, da steht doch die Zeile "fehler = fehler+dx", die bei einem Schritt in die langsame (x-)Richtung den Fehlerterm wieder ins Positive holt. --PeterFrankfurt 02:00, 20. Dez. 2006 (CET)
thread_title:  Anregung 

message: Hallo, im englischen und französichen Artikel sind Bilder eingebunden, könnten wir :Bild:Bresenham.png nicht auch einbinden? --Marco.Geisler 11:08, 2. Feb. 2007 (CET)
replies: text: Gute Anregung, gleich umgesetzt, obwohl mir da noch wesentlich aufwendigere Möglichkeiten vorschweben. Dabei habe ich auch gesehen, wie in jeder Version völlig andere Implementierungen als Beispiel aufgeführt werden, und die Kreisversion gibt es nur hier :-). --PeterFrankfurt 22:20, 2. Feb. 2007 (CET)
replies: text:  Vielen Dank! Mit dem Bild in versteht man das viel schneller. --Marco.Geisler 20:50, 4. Feb. 2007 (CET)
replies: text: Wer sich übrigens für den originalen Bresenham-Ansatz interessiert, der noch ein bisschen anders, geometrischer geht, sollte in die italienische Version reinschauen. Ich kann zwar mit meinem Mikro-Latinum kaum ein Wort lesen, die Bilder sprechen aber dafür, dass dort 1:1 nach Original-Bresenham vorgegangen wird. --PeterFrankfurt 16:07, 27. Feb. 2007 (CET)
thread_title:  Bild zur Veranschaulichung 

message: Hallo,
Der Konsistenz halber sollte man das Fehlerglied F mit (y-ystart)*dx - (x-xstart)*dy  definieren statt (x-xstart)*dy - (y-ystart)*dx. Wie man sieht wird im Algorithmus bei einem Schritt nach rechts dy vom Fehlerglied subtrahiert, statt addiert, wie die jetzige Formel vorgibt. Auch der Rest des Textes scheint sich auf die alternative Definition des Fehlerglieds zu beziehen (Fallunterscheidung: F < 0, F > 0).
:Oh, in der Tat, danke für den Hinweis. Ich hatte das sogar erst letztens selbst verschlimmbessert, sorry. --PeterFrankfurt 23:57, 16. Feb. 2007 (CET)
thread_title:  Fehlerglied 

message: Mich würde die hier angewandte Definition von "elegant" interessieren. Ich finde die erste Implementierung viel eleganter als die zweite, schon weil sie viel kürzer und einfacher ist. Natürlich ist sie weniger allgemein als die zweite, vielleicht sollte man "elegant" durch "allgemein" ersetzen?
Auch der Hinweis "..., das die Fallunterscheidung in acht Oktanten nicht ausdrücklich vornehmen muss" ergibt für mich keinen Sinn: genau das passiert doch am Anfang der Funktion mit diesen ganzen if-Klauseln (die für mich im Übrigen keineswegs unter elegante Programmierung fallen). Eriatarka 13:51, 27. Feb. 2007 (CET)
replies: text: Nun ja, das ist wahrscheinlich Ansichtssache. Jene "elegante Version" ist nicht von mir, und ich wollte sie durchaus als Kontrast zu meiner Simpel-Lösung stehen lassen. Wenn ich meine eigene Komplettversion für alle Oktanten anschaue, die ich hier auch vorliegen habe (allerdings in Assembler, also kaum zur Veröffentlichung geeignet), sieht sie wesentlich umständlicher aus. Insofern fand ich das Etikett "elegant" für angemessen. Also wie gesagt: "elegant" in relativem Sinn, im Vergleich zu anderen, noch weniger eleganten Lösungen. --PeterFrankfurt 16:04, 27. Feb. 2007 (CET)
thread_title:  Elegant? 

message: Es sollte darauf hingewiesen werden, dass sich der vorgestellte Code nicht für schnelle Rasterung eignet, da der Aufruf von malloc und das Schreiben in den Array viel Zeit kostet. --Phrood 19:17, 2. Mär. 2007 (CET)
replies: text: Tja, ich bin kein großer C-Guru, aber ich kann mir vorstellen, dass man das auch ein bisschen effizienter umformulieren könnte. Deswegen habe ich ja auch "elegant" drübergeschrieben, nicht "schnell" :-). --PeterFrankfurt 22:01, 2. Mär. 2007 (CET)
replies: text: Eigentlich ist der Algorithmus sogar für den ernsthaften Einsatz unpraktikabel. malloc bedeutet, dass eine API-Funktion aufgerufen wird (bei Windows z.B. VirtualAlloc), die Zeit für Aufruf+Ausführung braucht. Zusätzlich ist bei modernen Prozessoren jeder Zugriff auf den Speicher, besonders, wenn sich der Speicherbereich nicht im Cache befindet, furchtbar langsam. --Phrood 22:11, 2. Mär. 2007 (CET)
thread_title:  Elegantere Implementierung 

message: Der von PeterFrankfurt in diesem Artikel beschriebene Algorithmus ist nicht mit dem Bresenham-Algorithmus identisch und auch nicht äquivalent, da er andere Ergebnisse liefert. Es gibt dazu eine längere Diskussion auf Benutzer Diskussion:PeterFrankfurt#Weiteres Vorgehen. Es wäre wünschenswert, wenn sich noch andere Benutzer zu dem Sachverhalt äußern würden. --Phrood 22:36, 2. Mär. 2007 (CET)
replies: text: Der Algorithmus ist anders, aber doch äquivalent. Der Fehler im Vergleichstest der beiden Algorithmen wurde gerade erkannt. Der hier dargestellte Algorithmus liefert also doch identische Ergebnisse und gehört nach seinem Grundmechanismus eindeutig in die "Bresenham-Familie". Mir ist kein anderer passender Name für so einen Algorithmus bekannt. Code-Snippets zum Vergleichstest auf meiner Diskussionsseite. --PeterFrankfurt 23:21, 2. Mär. 2007 (CET)
replies: text: OK, der Fehler lag bei mir. Der Algorithmus ist tatsächlich äquivalent zu Bresenham. --Phrood 23:24, 2. Mär. 2007 (CET)
replies: text:  Mal abgesehen davon ob er äquivalent ist oder nicht: Dieser Artikel handelt doch von Bresenham. Dann sollte auch der diskutiert werden. Andere Artikel beschäftigen sich allgemeiner mit Linienrasterisierung. -- Odx 11:20, 16. Feb. 2010 (CET)
replies: text: Deswegen gibt es doch die Gegenüberstellung mit dem originalen Algorithmus, er wird ja nicht verschwiegen. Jedermann kann das über den verlinkten Originalartikel nachvollziehen. Hier geht es ja nur um eine leicht abweichende Implementierung, nicht um einen ganz anderen Algorithmus, das wäre ja nochmal was anderes. --PeterFrankfurt 01:27, 17. Feb. 2010 (CET)
thread_title:  Bresenham oder nicht? 

message: Mir scheint, der Bergriff Matrixanzeige wird nur bei kleinen Displays und nicht bei normalen Bildschirmen verwendet. --Phrood 18:57, 12. Mär. 2007 (CET)
replies: text: Das sind bloß die Beispielbilder in dem Artikel, der Begriff selbst und auch der Artikeltext gilt vollkommen allgemein. --PeterFrankfurt 19:45, 12. Mär. 2007 (CET)
thread_title:  Link auf Matrixanzeige 

message: Die Implementierung des Algorithmusses für Kreisränder in C hat eine kleine unschöne Stelle. Für den Fall x=y werden die Punkte doppelt gezeichnet. Das macht den Algorithmus nicht falsch, dennoch gefällt es mir nicht. Man sollte im Text zumindest einen Hinweis dazu schreiben. Eine Verbesserung ist meiner Ansicht nach nicht möglich, da ein Test auf Gleichheit an dieser Stelle möglicherweise mehr Rechenaufwand bedeuten würde als einfach den Pixel noch einmal zu setzen.
Ich komme darauf weil ich bei einem Datenanalyseproblem gerade die Summe aller Helligkeitswerte auf einem Kreisrand in einem Bild benötige. Mir ist dabei aufgefallen dass die vorgestellte implementierung die oben genannte Eigenschaft hat. Um anderen Benutzern mit ähnlichen Problemen zu helfen sollte zumindest erwähnt werden dass manche Punkte doppelt gesetzt werden.
Gruß,
Roland Winkler 
:Ja, das ist ein bekanntes und nach meiner Kenntnis bisher nicht befriedigend gelöstes Problem. Es kommt nämlich auf den Radius an, nach dem es zwei Fälle gibt: Beim einen Fall liegt der letzte Punkt eines Oktanten genau auf der Diagonalen, und wenn man den Nachbaroktanten genauso zeichnet, kommt dieser Punkt doppelt. Im anderen Fall liegt der letzte Punkt eines Oktanten direkt vor der Diagonalen und der entsprechende Punkt im Folgeoktanten genau ein Pixel diagonal versetzt, so dass es dann keinen Konflikt gibt. Wie man diese Fälle sauber und trotzdem elegant erkennt, muss noch jemand vormachen, ich habe das noch nicht gesehen, und selbst finde ich auch keine richtig gute Lösung. Aber die Angelegenheit behalte ich im Auge. - Aus meiner Erfhrung, wo ich mit mechanischen Plottern zu tun hatte, ist das Problem vor allem dann akut, wenn man die Nachbaroktanten durchgehend zeichnen will und den zweiten dabei also "rückwärts" angehen muss, dann sind diese Punktdoppelungen erst recht übel. Ich hatte mich da immer mit absoluten Koordinaten und schlimmstenfalls Mehrfachanfahren desselben Punktes beholfen (Hauptsache, ich bekomme keinen ungewollten Versatz um so ein Diagonalpixel hinein), aber das war weder elegant noch schnell, eher eklig... --PeterFrankfurt 02:11, 12. Apr. 2008 (CEST)
thread_title:  Implementierung des Algorithmuses für Kreise 

message: Ich bin dafür, unter diesem Lemma eine BKL zu Rasterung von Linien und Rasterung von Kreisen anzulegen, wo die beiden Bresenham-Algorithmen bereits beschrieben werden. Erstens ist es unschön, in einem Artikel zwei verschiedene Algorithmen zu beschreiben. Zweitens ist es nicht die Aufgabe eines Artikels, verschiedene Implementierungen eines Algorithmus in unterschiedlichen Sprachen zu liefern, sondern nur das Prinzip zu demonstrieren, am besten mittels Pseudocode, und das leisten die genannten Artikel m. E. besser. --Phrood 23:04, 27. Apr. 2008 (CEST)
replies: text: Hmm, eine BKL für gerade zwei Varianten halte ich für übertrieben. Im Übrigen würden die Vorschläge im Endeffekt auf eine Löschung dieses Artikels hier hinauslaufen, wofür ich natürlich nicht zu haben wäre. --PeterFrankfurt 02:09, 28. Apr. 2008 (CEST)
replies: text: BKLs mit nur zwei Einträgen sind nicht unüblicher als andere. Redundanzen sollten grundsätzlich vermieden werden. Welche der hier erwähnten Informationen fehlen dir denn in den beiden anderen Artikeln? --Phrood 07:14, 28. Apr. 2008 (CEST)
replies: text: Eben die konkreten Implementierungen und die Herleitung der Bresenham-Methode, wie sie hier dargestellt wird. Ich habe schon mal eine Mail von einem User bekommen, der sich ausdrücklich für das direkt benutzbare Listing bedankte, weil er es so erst richtig verstehen konnte. (Mir geht es mit sowas genauso, deshalb lege ich da auch so Wert drauf.) -  Die Redundanz wird doch schon dadurch vermieden, dass in Deinen Übersichtsartikeln vor allem die Familie im Vergleich von ähnlichen Algorithmen präsentiert wird, während sich hier auf diese eine Variante und ihre Implementierung konzentriert wird. Das kann man wunderbar verantworten. --PeterFrankfurt 00:38, 29. Apr. 2008 (CEST)
thread_title:  BKL anlegen 

message: Kann ich den "Bresenham" beliebig verwenden, oder kollidiere ich dann mit irgendeinem Urheberrecht ? --dreysacz 11:02, 14. Jul. 2008 (CEST)
replies: text: Ein Patent wäre mittlerweile abgelaufen, ansonsten gibt es für solche Erfindungen keinen Urheberschutz, der den 75 Jahren für künstlerische Produkte vergleichbar wäre. Man kann das beruhigt benutzen. Man kann auch gern den Namen als Referenz in Kommentaren oder so erwähnen, um sich nicht mit fremden Federn zu schmücken. Aber Lizenzgebühren braucht man keine zu zahlen. --PeterFrankfurt 00:06, 15. Jul. 2008 (CEST)
thread_title:  Urheberrecht 

message: Im Artikel ist die Rede vom ersten Oktanden aber imho ist der Bresenham doch für zwei Dimensionen. Sollte das nicht Quadrant heissen? 
: (bitte unterschreiben) Jein, es geht um was anderes: Das Verfahren ist erstmal nur für Steigungswinkel von 0 bis 45 Grad geeignet. Um auf den ganzen Kreis zu kommen, muss man das 8 Mal nehmen, deswegen spricht man (in der Ebene) von 8 Oktanten = 8 Winkelsektoren a 45 Grad. Die 8 kann man als 2 hoch 3 ansehen, man braucht also 3 binäre Fallunterscheidungen, um alle diese 8 Fälle abzudecken: 1. Vorzeichen von dx, 2. Vorzeichen von dy, 3. Vertauschung der Rolle von x und y. Macht 8 Fälle/Oktanten. --PeterFrankfurt 01:54, 3. Nov. 2008 (CET)
replies: text: Siehe Oktant_(Geometrie)#Oktanten im zweidimensionalen Raum. Vielleicht sollte ich dort nochmal eine Grafik zur Veranschaulichung dazupacken, was meint ihr? --RokerHRO 09:19, 3. Nov. 2008 (CET)
replies: text: Ah, jetzt sehe ich erst, woher die Frage kam, weil in dem verlinkten Oktantenartikel diese 3D-Darstellung dominiert. Ich habe den Link mal auf das Unterkapitel präzisiert, was in der Praxis allerdings wegen der Kürze des Artikels nichts an der Anzeige ändert... --PeterFrankfurt 23:30, 3. Nov. 2008 (CET)
thread_title:  Oktand? 

message: Unter welcher Lizenz steht der C-Code?
Würde ihn gerne in einem großen open-source project nutzen, das es jedoch auch in einer proprietären version gibt (und dort auch ohne probleme nutzbar sein sollte). (nicht signierter Beitrag von 213.47.219.86 (Diskussion | Beiträge) 19:19, 11. Aug. 2009 (CEST)
replies: text: Angelehnt sind diese Codebeispiele ja an jeweils aufgeführte Literaturstellen, die sollte man ggf. zumindest erwähnen. Und alle WP-Inhalte stehen sowieso unter Wikipedia:Lizenzbestimmungen, die laufen auch darauf hinaus, dass das in Open-Source-Projekten immer verwendet werden darf, aber halt mit Erhaltung der Herkunftsangabe. --PeterFrankfurt 01:47, 12. Aug. 2009 (CEST)
thread_title:  Lizenz des C codes? 

message: Habe versucht, das Ding aus dem Basic-Code nachzuprogrammieren und bin über die Variablen es und el (Fehlerschritte schnell bzw. langsam) gestolpert. Liegt hier eine Vertauschung vor? Sollte nicht, wenn x die schnelle Richtung ist auch es = adx sein (dito bei y als schnelle Richtung). Wenn immer ein Pixel in die schnelle Richtung gezeichnet wird, sollte die Schleife bis es laufen, oder? Bin mir nicht sicher, ob es mit einer konsistenten Umbennenung getan ist. --Rat 11:38, 9. Sep. 2010 (CEST)
replies: text: Nein, das ist ja gerade der Trick, dass die Koordinaten "überkreuz" verwendet werden: Vom Fehlerglied wird bei jedem Schritt die kleinere Absolutdifferenz es abgezogen und nur bei den Diagonalschritten die größere Absolutdifferenz el wieder draufaddiert. Dieses Überkreuzsubtrahieren und -addieren entspricht (wie irgendwo im Artikel erläutert) der Rückführung der Division (für den Steigungsfaktor m=dy/dx) auf Subtraktion und Addition. --PeterFrankfurt 03:18, 10. Sep. 2010 (CEST)
thread_title:  Fehler in der "eleganten" Implementierung? 

message: Die Abbildung zur Kreisvariante des Algorithmus (Untertitel "Rastern einer Kreislinie nach dem Bresenham-Verfahren") ist nicht korrekt. Der von links gezählt achte Pixel (der letzte vor dem auf der Diagonalen) muss um einen Pixel weiter nach unten versetzt werden. Der Grund ist, dass für x=7 (was der betrachteten Spalte entspricht) ein exakter y-Wert von Sqrt(11^2-7^2)=8,485... herauskommt, also ein Wert, der gerundet eben nicht 9, sondern 8 ergibt, was der um eins nach unten versetzten y-Position entspricht. Für jeden ganzzahligen x-Wert muss der y-Wert des idealen Kreises nämlich einfach auf den nächsten Ganzzahlwert gerundet werden, um einen Pixel zu bekommen, der nach dem Bresenham-Algorithmus erstellt werden würde. Dies gilt für alle Bresenhamartigen Algorithmen, da diese die sog. Grid-Intersection-Digitization implementieren.
Dies deckt sich auch mit dem tatsächlichen Ergebnis, das sich mit der angegebenen Implementation ergibt. Wenn man diese durchlaufen lässt, ergbt sich eine Kurve der folgenden Form:
 x x x x
         x x
             x
               x x
                 x 
                   x
                   x
                     x
                     x
                     x
                     x
Dasselbe gilt übrigens für den englischen "Midpoint circle algorithm"-Artikel und ggf. für weitere Sprachen.
--Plotin3D (Diskussion) 12:33, 9. Okt. 2012 (CEST)
thread_title:  Fehler in Bresenham-Kreis-Abbildung 

message: Meiner Ansicht nach ist dies, so wie es dort beschrieben steht, nicht ganz richtig. Man kann so einen Kreisbogen von alpha bis beta nämlich doch ohne Trigonometrie/Wurzelrechnung zeichnen, indem man einen ganzen Kreis entlang läuft, die Wertpaare (x,y) zwischenspeichert (z.B. als Array) und hinterher dieses Array nochmal durchläuft, wobei man nur die Punkte tatsächlich zeichnet, für die a <= i <= b  mit a < b gilt. Dabei ist i der Arrayindex, a ist gerundet "N * alpha/2*Pi" und b ist gerundet "N * beta/2*Pi". Die int-Variable N steht wiederum für die Gesamtanzahl an Paaren (x,y), die man ja beim Durchlaufen des Kreises ermitteln kann. Ich hoffe ihr versteht, was ich meine. Ob das ganze wirklich schneller ist, als mit trigonometrischen Funktionen und Wurzelberechnungen, wage ich jedoch zu bezweifeln, denn es müssen wiederholt eine Menge Daten kopiert werden. 
Ich habe es selbst so implementiert und könnte bei Bedarf meine Lösung mal hochladen.--130.75.180.129 23:58, 6. Aug. 2013 (CEST)
replies: text: Du hast vollkommen recht. Dass da im Artikel steht, man "muss" es so und so machen, ist in der Tat nicht korrekt. Mach aus dem Obigen doch einfach mal einen koonkreten Formulierungsvorschlag, da kann man sich bestimmt einigen. --PeterFrankfurt (Diskussion) 00:05, 8. Aug. 2013 (CEST)
thread_title:  Zum Abschnitt: "Zeichnen nicht-vollständiger Oktanten"