Talk:Xiaolin Wu's line algorithm

From Wikipedia, the free encyclopedia

The extension to cover nearly-vertical lines is trivial, and left as an exercise for the reader.

Doesn't get any more aloof than that, gentlemen.

Indeed it doesn't, and could frustrate someone coming to Wikipedia for algorithm help (I know I have). If they haven't studied Bresenham's algorithm the way to fix it may not be so obvious. I'll edit the article.

Contents

[edit] This Article needs some Images.

Maybe even readers not able to use a compiler themselves may want to know what it looks like...

[edit] Typo in code?

   // check that x1 < x2
   if x2 < x1
       swap x1, x2

Surely just swapping x1 and x2 creates a mirror-image of the line? Shouldn't y1 and y2 also be swapped?

This is what is done in Bresenham's_line_algorithm:

    if x0 > x1 then
        swap(x0, x1)
        swap(y0, y1)

[edit] The nearly-horizontal case

"the nearly-horizontal case (Δx > Δy)"

makes more sense (to me) if it would read

"the nearly-horizontal case (Δx ≫ Δy)"

Am I missing something obvious here?

- Yes, the word "nearly" is a bit misleading. Δx > Δy is just the more-horizontal-than-not case, in which one can iterate over x to draw all the points. 80.137.89.203 17:07, 1 August 2006 (UTC)

[edit] Posted Pseudo-Code Works

FYI, I used the pseudo-code posted on the wiki page as the basis for my own Wu line generator in C++ combined with SDL (Simple DirectMedia Layer). It works very well, is very fast, and can be easily generalized to other octants in the plane. Thanks a ton to the original poster.

- I just implemented this in python and IMHO "ipart(x) == integer part of x" should be clarified to really mean floor(x), that is for negative numbers (like -2.5) it should still round down (to -3.0) instead of to the integer part (-2.0). Also i used "1.0-(intery-floor(intery))" to calculate the alpha (also because of negative numbers) 80.137.89.203 17:18, 1 August 2006 (UTC)

[edit] Diagonals

This algorithm doesn't antialias diagonal lines (+45°, -45°, +135°, -135°) nor lines close to these angles aren't antialiased very visibly. Maybe this should be mentioned? 82.229.207.75 09:07, 15 December 2006 (UTC)

-

It should probably be noted - it was in the paper and by any authoritative coverage of the algorithm. Horizontal, vertical, and diagonal lines are special case scenarios that simply shouldn't be handled by the Wu algorithm as it can be done much faster using special code; the pixel weightings are constant, after all. 83.84.34.115 00:07, 14 March 2007 (UTC)

[edit] Author

Does the article link to the correct Xiaolin Wu? His website has no mention of anti-aliasing algorithm. --24.13.179.215 04:21, 24 June 2007 (UTC)

[edit] Code error?

Shouldn't be this code inside the distinction between horizontal-ish and vertical-ish lines? The way it is implemented now can have the result that after swapping x and y, x2 is again smaller than x1.

   if x2 < x1
       swap x1, x2
       swap y1, y2
   end if

194.78.35.195 (talk) 15:29, 19 February 2008 (UTC)