Hot palette

Diamond shapes

Holes

There are two frequencies involved here. Call them x and y. When one is much larger than the other you get horizontal or vertical waves. If they are nearly equal you can see both types of waves.

Vertical waves in two colors. Playing with the direction and density.

In this variation the colors are not blended. Where they would otherwise overlap, one color is selected, rather than trying to blend them.

For the nerds out there, the bug was one of those kind of bugs. Internally I represent each color channel by a (continuous) floating point value between 0 and 1. The graphics hardware and the bitmap file format uses (discrete) byte values between 0 and 255. So one must multiply or divide by 256, depending on direction, for conversion. At one point I wrote 255 instead of 256. I looked at that number many times and it did not occur to me that it was wrong. The small difference is barely noticeable.

Small tweaks to the parameters, and added a black stripe to the vertical palette.

I had put in several parameters to fine tune the results. While the results were close to my intent, the parameters did not work as I expected. Sometimes I liked the unintended results. But mostly it was frustration trying to get better control over the finer details.

Here are multiple overlapping horizontal waves with slightly different frequency, amplitude, and phase. (Meaning they do not neatly line up.)

My code had a bug, and I spend way too much time hunting it down. In the process I generated many images trying to isolate the problem.

Actually there were two problems. One was an actual bug, the other probably should be called a prototype. I had an idea of what I wanted, wrote some code that I thought might work, but I was not sure. So I tried it to see what would happen. The result was close to, but not quite what I intended.

Anyway, I imagine that someday I will find a way to use these, with much reduced contrast, as background, and then put something to serve as a focal point in the foreground.

There is a lot of room between those two extremes, here are I few I feel are close to the middle.

Nature abounds with good examples. I am not trying to reproduce nature per se, but rather the abstraction of an interplay between random and not random.

The images could be a polished marble surface. I enjoy looking at the shapes and grain in stone and wood and similar surfaces. The patterns on a similar faux surface hold my interest only until I see where they repeat, then disappointment, as I can never not see the repetition again.

So, what about these pictures?

I used simple things like lines to test my anti-alias code changes. When that was looking good I wanted a more complex example like a fractal. A fractal with a lot of details takes a while to generate, so I decided to look for something simpler and quicker. This is the result.

If you put the previous image side by side with this one you will see the difference that anti-aliasing makes. This one uses a simple average on four point on grid within a pixel. In sub-pixel coordinated, the sample points are (0.25, 0.25), (0.25,0.75), (0.75,0.25) and (0.75, 0.75).

(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 3x3 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 4x4 grid may give better results. A 2x2 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.

All of the images in this blog, until recently, use a process called anti-aliasing. See https://en.wikipedia.org/wiki/Supersampling

If, for example, you want to draw a line on the computer screen, you could calculate which pixels are on the line and light them up. This almost works. We naturally think of a pixel as a zero-dimensional point, and the line as one dimensional. But a line needs some width, or it would be invisible, and a single pixel covers some small area of the display. A typical monitor has about 100 dpi, so a pixel is actually a 0.01 inch x 0.01 inch square. The pixels are very small, but if you build a diagonal line out of these square pixels, you will still see the corners of the individual pixels. The line looks jagged.

These edge pixels are not entirely on or entirely off the line. The line covers some intermediate portion of the pixel. A better way to draw these pixels is to consider the partial coverage. If the line covers 30% of the pixel, then give the pixel a blend of 30% the line color and 70% the background color.