Refactor 2022 #4

530.jpg

(Anti-Aliasing continued) In the line example it is possible to calculate the percentage of the pixel covered by the line. Then one can do anti-aliasing as described in the previous post. Squares and lines are simple things. The percentage calculation is not possible in general.

Generative art, such as fractals, but also anything more complex than simple geometric objects, also suffer from the equivalent of jagged lines. It is no longer a question of “in or out”. That single pixel may contain many colors. Choosing just one of the colors generates noisy (sparkly) images. So in this case one samples several points within the pixel area and averages the results.

A very long time ago I set up an anti-alias method by sampling nine points on a 3×3 grid inside the pixel and then taking the simple average of the colors. That was the first thing that I tried, it worked well enough so I did not try anything else. I carried that code forward from program to program over the years.

There are other ways to the job. A 4×4 grid may give better results. A 2×2 grid would take less than half the time. Five points, four corners and the center may be good enough. Arguments could be made for a weighted average rather than a simple average. Also a good case can be made to use random points rather than points on a gird.

As part of this refactor journey I decided to add these options to my anti-alias code. I can then tweak the parameters and choose the best tradeoff between speed and noticeable quality improvement.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.