%CustomEntities; %CourseEntities; %CommonEntities; ]>

Summary: You've already learned about a number of basic techniques that you can use in making images, including region-based color blends, and even the basic GIMP tools. In this reading (and the corresponding lab), we will consider a few more techniques that you might find useful.

In the reading on deep recursion, we encountered an interesting way to use trees: We can represent an image with a color tree, a tree whose leaves are all colors. We can then render the tree systematically. In that first rendering algorithm, when we encountered a pair, we split the image (or subimage) horizontally and then rendered the left half of the tree in the left half of the image, and the right half of the tree in the right half of the image. It can be more interesting (and more valuable) to render a color tree by alternately decomposing the image horizontally and vertically. The following alternate definition does just that. (You may find it valuable to study it for a moment.) How can color trees be useful for the project? Well, if you're willing to put up with fairly unpredictable images, you can write a procedure that systematically builds a color tree from an integer. But how do we build an interesting color tree? One strategy is to look at some characteristic of the number (e.g., the remainder after dividing by ten) and use that number to decide how one might split the number (e.g., if the remainder is 1 or 2, we build a color tree whose left subtree is built from some fraction of the number and whose right subtree is built from some other fraction of the number. If the remainder is 3 or 4, we build a color tree whose left subtree is a different fraction, and so on and so forth. Here's an implementation of that technique. Here's one way to incorporate that procedure into a series of images. You'll have a chance to explore these ideas a bit more in the lab.

Color trees provide one way of decomposing and then rebuilding an image. But, at least as created using the techniques above, they create unpredictable images. As we explore in this section, one can more systematically build an image by decomposing it into smaller pieces. A mathematically interesting kind of drawings is what is commonly called a fractal. Fractals are self-similar drawings. That is, each portion of the drawing bears some resemblance to the larger drawing. We normally draw fractals by breaking the larger drawing into equal portions and drawing each portion using the same technique. For example, to draw an NxM rectangle, we might draw nine (N/3)x(M/3) rectangles in a grid. Similarly, to draw each of those nine rectangles, we might draw nine (N/9)x(M/9) rectangles, and so on and so forth. When do we stop? When we've recursed enough or when the rectangles are small enough. We might express this technique in code as follows. Why would we use such a technique, since all we end up with is the same rectangle? Well, things get a bit interesting when you make subtle changes (other than just the level of recursion) at each recursive call. Most typically, you might draw the different subrectangles in modified versions of the original color. Once you do that, you can also think about changing whether or not you use an even grid, or even whether or not you draw each sub-rectangle. The technique sounds simple, but it can produce some very interesting images. More generally, fractals also let us provide interesting simulations of many natural objects, such as trees, mountains, and coastlines, that have some of the same self-similarity. We'll start our explorations with these rectangles. What can we do? Well, instead of drawing all sub-rectangles the same way, we can vary them a bit. For example, we might draw some of the sub-rectangles in the complement of the color, in a lighter version of the color, or in a darker version of the color. We might break up the rectangle into a less even grid. We might use different levels of recursion for different sub-rectangles. We will explore these kinds of options in the corresponding lab.

One of the more interesting applications of algorithms to images is so-called genetic art. In this technique, we build some form of image DNA, generate images from that DNA, rank the fitness of the images, and recombine the DNA, of images the DNA of more fit images more frequently in building the next generation. Electric Sheep are one of the more famous examples of genetic art. Of course, the first part of genetic art is figuring out how to turn the DNA into an image. A spectacular variety of techniques exist for such transformations. Dr. Davis has one famous early example (done by hand, rather than by computer), in which Francois Morellet used a phonebook as the DNA, and rendered it in a large grid using red for odd digits and blue for even digits. We'll consider two versions of this repurposing of data: One in which we use this same grid technique to turn a file into a series of pixels (or blocks of colors or ...) and another one in which we turn a file into a series of instructions to a turtle. We've already seen a bit of how we can interpret any file as a series of colors: We could read triplets of characters and treat each triplet as a new color. Here's one implementation of that technique, using image-calculate-pixels!, a slower variant of image-compute-pixels! that traverses the image systematically, row by row, from top-left to bottom right. One problem with that technique is that it provides a fairly wide variety of colors, giving no form at all to the image. It also doesn't scale appropriately. A simpler technique is to choose a smaller palette of related colors and use the characters as indices into that palette. That is, we pick sections of the image to draw (most simply, a grid of rectangles or ovals), and, for each section, read a character, convert the character to an integer, reduce that integer to the range of valid indices, and then get it from the palette. We might use such a procedure to make a wide variety of images by selecting palettes, files, horizontal boxes, and vertical boxes from n. While these grid-like visualizations of files are fun, they are certainly not the only thing we can do to interpret a file as the DNA of a drawing. As mentioned above, we can treat a file as a series of commands to a turtle. Unfortunately, this procedure is a bit less refined than most. Still, it may be worth exploring.