Month: June 2022

The New Palettes #3

Posted on by earl
575.jpg

What about the port / refactor? If you have been following this blog, I have been talking about modifying software for the last six months. Well, that is still going on, with no end in sight. Creating a larger collection of starting color sets is one of the tasks on the list.

Even though these pieces are the result of software development / testing, I put in more effort than a simple test requires. They deserve a stand-alone collection rather than being just filed under “Refactor 2022”.

The New Palettes #2

Posted on by earl
574.jpg

I started building these with adjacent squares of different colors. That quickly became old and redundant. It was difficult to envision the colors in a final design. So I invested a little in the overall shape. Still mainly vertical swatches of colors to evaluate the color combinations. But not just simple geometric shapes. The swatches are more messed up, creating enough interest that I would hang it on my wall.

The New Palettes #1

Posted on by earl
573.jpg

It is time to try out some new color combinations.

I have some favorite default color palettes, blue/brown, black/white, rainbow. Typically I work with one of these default color sets, and focus on shapes and arrangements. Often the process stops there, and the default palette becomes the final palette. Reworking the colors seems like a lot of effort, the arrangement is the main thing, and I am usually eager to start on the next picture. When I make an effort to redo the design in different colors, I tend to use bright, saturated colors. Subtle colors takes more patience

So I am trying out some new (for me) color sets. Colorful, but not dominated by fully saturated colors. I hope to build a bigger tool box of starting color sets, then the final design step should be small tweaks rather than a full reset.

Refactor 2022 #39

Posted on by earl
568.jpg

My program was initially designed for fractals, and so it has a strong pixel-first bias. I do jump back and forth between the two methods, but within the program they are not symmetric. Things in the program are optimized for pixel-first, object-first tasks seem like a kludge. So for the refactor I am trying to balance things out and make it easy to choose between pixel-first or object-first methods.

Refactor 2022 #38

Posted on by earl
567.jpg

Object-first is an easy choice with many small squares. There are many squares, each affecting just a few pixels. A pixel-first approach would result in many empty tests. Each pixel is tested against each square. Almost all of those tests are false, resulting in a do-nothing step.

Of course the key is that for the object, in this case a square, there is an efficient way to say in bulk which pixels are covered by the square. All those do-nothing, not-in-the-square tests are avoided.

Refactor 2022 #37

Posted on by earl
566.jpg

In theory, one could draw the image either way. The pixel-first method would pick a pixel, test each square to determine if it contains the pixel. Determine a color based on those squares, color the pixel. Then move on to the next pixel.

Object-first seems more natural, it is how I would paint this without a computer. Also the algorithm seem more intuitive.