A mosaic is a picture made up of lots of smaller pieces. The ancient
Babylonians constructed elaborate mosaics using colored tiles. A
photomosaic is a mosaic, except instead of using single color
tiles for the tiles, it uses photographs. For some example
photomosaics, see
http://www.photomosaic.com/portfolio.html.
Making a photomosaic is a big task. The way computer scientists (and most other people) solve big problems, is to break them into a few smaller sub-problems whose solutions can be combined to solve the original problem. This approach is sometimes called divide and conquer.
Note that for a big problem like making a photomosaic, doing this once is probably not enough. The sub-problems are still too big to solve easily. So, we need to use divide-and-conquer again to break each sub-problem into several sub-sub-problems. We do this recursively, until we get to sub-sub-sub-...-sub problems that are small enough that we can solve them easily.
We can describe this process with pseudocode (that is, not real Scheme, but made to look like it):
(define (solve-big-problem problem)
(if (easy-to-solve? problem) ; if the problem is easy to solve,
(solve problem) ; just solve it!
(combine-solutions ; otherwise, combine the solutions
(map solve-big-problem ; of solving
(divide-problem problem))))) ; the sub-problems you
; get by dividing the
; original problem
Here, map is a function that applies another function to every
item in a list. The (divide-problem problem) evaluates to a
list of sub-problems. The value of (map solve-big-problem
(divide-problem problem)) is the result of applying
solve-big-problem to every sub-problem in that list.
Implementing solve, combine-solutions and divide-problem for a real problem is the difficult part. There is a real art to figuring out how to divide a big problem into a suitable set of smaller problems. Being able to do this well is the main thing that separates good problem solvers from mediocre ones.
If any expression evaluates to something different from what you expected in Question 1, figure out why. Don't change your answers to Question 1, but instead write down explanations of why you think DrScheme produces the value it does instead of what you expected. (You don't lose any points on Question 1 or 2 if your answers are wrong, but you must fully attempt the questions.)
A (not too brilliant) kindergartner could follow these directions to make a photomosaic:
We will create a photomosaic using Scheme in almost the same way — except the computer is much dumber than our kindergartener, so we need to break the steps into even smaller problems before it can perform them. (Our computer won't need to break for milk and cookies, but it will need to collect garbage.)
In step 7.a.i. the kindergartner has to look through the tile pictures to find one that best matches the color on the master picture under that rectangle. Your task for this problem set will be to define a function that does that.
First, we explain how the rest of the photomosaic program works. We show lots of code here, but don't worry if you don't understand all of it. You should attempt to understand how it works, but it is not necessary to completely understand all the code shown here to complete this assignment.
We can divide the photomosaic problem into three big steps:
This file contains:
You should look at the mosaic.ss (but don't worry if you don't understand much of the code in that file), but you will only need to change and turn in ps1.ss. If you double-click on ps1.ss, it should open in DrScheme. Click the Execute or Run button (or use ctrl+T) to interpret the definitions. DrScheme will split into two windows, with an Interaction Window on the bottom. If the language is set correctly, you should see:
Welcome to DrScheme, version 352.in your Interactions Window.
Language: Pretty Big (includes MrEd and Advanced).
>
All colors can be created by mixing different amounts of red, green and blue light — if you look closely at a television, you will see the whole image is made up of red, green and blue dots. We can represent a color using three numbers representing how much red, green and blue is in the pixel. For most computer images, there are a limited number of colors. In the images we will use, there are 256 different intensity values for each color. Hence, we can represent a color using three values between 0 and 255 to represent the amount of red, green, and blue in a pixel.
For example, (0 0 0) is black, (255 255 255) is white, (255 0 0) is red, (0 0 255) is blue, and (255 255 0) is yellow (mixing red and green light makes yellow).
The file mosaic.ss (included in the ps1.zip file you downloaded) defines some procedures for manipulating colors:
(define white (make-color 255 255 255)) (define black (make-color 0 0 0)) (define red (make-color 255 0 0)) (define green (make-color 0 255 0)) (define blue (make-color 0 0 255)) (define yellow (make-color 255 255 0))In your interaction buffer, try evaluating (show-color red).
You should see a small window appear containing a red rectangle:
We can say color 1 is brighter than color 2 if the sum of the red, green and blue values of color 1 is greater than the sum of the red, green and blue values of color 2. This may not correspond exactly to our intuitive perception of colors, but it should be pretty close.
(define (brighter? color1 color2) ;;; Fill in the code here that determines if color1 is brighter than color2 ;;; A good definition will need only a few lines of code. )Hint: you may want to use functions such as get-red.
Test your procedure by evaluating it with several different parameters. For example, you should get these results:
> (brighter? white red)
#t
> (brighter? red white)
#f
> (brighter? red red) ;; red is as bright as red, but not brighter
#f
> (brighter? red blue)
#f
> (brighter? yellow red)
#t
A computer represents an image by a bitmap. A bitmap is a two-dimensional array of picture elements (pixels). Each pixel is just one dot of color. A bitmap is actually a dotmosaic, where the tiles are individual colored dots.
Instead of storing images as bitmaps, we usually store them using a compressed format such as a GIF or a JPG. Compressed images take up less memory on the disk or to download, but are harder to manipulate. Fortunately, the DrScheme environment includes functions for converting them to bitmaps so we don't need to worry about it. We can store our images in compressed formats and use library functions to convert them into bitmaps when we use them in our program.
The pixels in a bitmap are numbered on a grid. The top left corner is (0, 0). If the bitmap is w pixels wide and h pixels high, the bottom right corner is (w - 1, h - 1).
To select tile images for our photomosaic we follow steps 5 through 7 from the kindergartener description. We don't need to worry about programming step 6 (naptime), but if you are working with a partner do keep remembering to switch places with your partner.
To find a tile image that matches a rectangle of the master image, we need to know the colors of both the tile images and rectangles in the master image.
To find a matching tile image, we need to know the "color" of each tile. One way would be to calculate the average color of each pixel in the tile image by adding the red, green and blue values for each pixel and dividing by the number of points. For example, if we wanted the average color of red (255 0 0) and blue (0 0 255) would sum the colors to get (255 0 255), and divide by two to get (127.5 0 127.5). This looks like purple, which is what you might expect:
| (255 0 0) | + | (0 0 255) | = | (255 0 255) | / 2 = | (127 0 127) |
(define (add-color color1 color2)
(make-color (+ (get-red color1) (get-red color2))
(+ (get-green color1) (get-green color2))
(+ (get-blue color1) (get-blue color2))))
To average many colors, we need to add all the colors together and
then divide by the number of colors. One way to add a list of values
together is to divide it into two simpler problems: add the first
value to the sum of all the other values. That is,
SUM (a, b, c, d, e) = a + SUM (b, c, d, e)We can do the same thing for the remaining values:
SUM (b, c, d, e) = b + SUM (c, d, e)
SUM (c, d, e) = c + SUM (d, e)
SUM (d, e) = d + SUM (e)
SUM (e) = e + SUM ()
SUM () = 0
The only tricky part is knowing what to do at the end when there are no
colors left. We define the SUM of no values to be 0.
Similarly, when there are no more colors left, we evaluate to the
0-color (black).
This is how we define sum-colors:
(define (sum-colors color-list)
(if (null? color-list) ;;; If there are no more colors in the list,
(make-color 0 0 0) ;;; evaluate to the 0-color (black)
(add-color ;;; Otherwise, evaluate to the result of adding
(first color-list) ;;; the first color and
(sum-colors ;;; the sum
(rest color-list))))) ;;; of all the other colors.
To calculate the average color of a bitmap, we just calculate the sum
of all the colors of the pixels in the bitmap, and divide by the
number of pixels.
For the photomosaic code, we don't want to look at every single pixel though since there are millions of pixels in a large image. Instead, we sample points from the image by selecting points at regular intervals. We do this by defining generate-sample-points a function that selects the points to sample, and applying average-colors to the result of mapping every sample point to the color of the bitmap point.
We need to divide the master image into tile-sized regions and calculate the average color of each region. This is almost the same as calculating the average color of a bitmap, except here we want the average color of lots of different regions within a single image.
Luckily we've already written a procedure that does almost what we need! We can use the generate-sample-points procedure to do this. To divide the master image, instead of just sampling the color of points, we generate a tile region with the sample point as its bottom left corner with the appropriate width and height.
We now know how to:
So, we define select-mosaic-tiles to take: a list of lists of color samples for regions in the master image (one list for each row) and a list of the tiles (where each tile is a list of a image name and the average color for that tile) and evaluate to a list of lists of images that describes the photomosaic.
Here's the rough code:
(define (select-mosaic-tiles samples tiles) (map2d find-best-match samples))The map2d procedure (defined in mosaic.ss) is like map, except it works on lists of lists. It applies the procedure find-best-match to every inner element in a list of lists.
We need to pass the tiles to find-best-match, though, and we also want to pass a function for matching colors. So, the actual select-mosaic-tiles code is:
(define (select-mosaic-tiles samples tiles color-comparator)
(map2d
(lambda (sample)
(tile-name (find-best-match sample tiles color-comparator)))
samples))
The find-best-match function goes through the list of tiles,
and selects the tile that best matches the sample color for this
rectangle.
The lambda means "make a procedure", so the expression evaluates to a procedure that takes one parameter (sample) which is the average color of the master image for this square. It evaluates (find-best-match sample tiles color-comparator) to find the tile in tiles that best matches the sample color, using the color-comparator procedure to compare two colors (this is the procedure you will need to write for the last question).
Finding the best match is like summing a list of colors — we can break it down into checking if the first one is better than the best one of the rest of the list. That is, if we had a function better-match that can determine which one of two possible tiles is a better match for a particular sample, we can use it like add-colors to find the best match from a list of tiles. As with add-colors, we have to be careful about what happens when there are no colors to add. It doesn't make sense to find the best match if there are no tiles, so we produce an error in that case. If there is only one tile, we know that is the best one. Otherwise, we compare the first tile with the best one we found from the rest of the tiles.
Here's the code:
(define (find-best-match sample tiles color-comparator)
(if (null? tiles) ;;; If there are no tiles,
(error "No tiles to match!") ;;; we lose.
(if (= (length tiles) 1) ;;; If there is just one tile,
(first tiles) ;;; that tile is the best match.
(pick-better-match ;;; Otherwise, the best match is
sample ;;; either the first tile in tiles,
(first tiles) ;;; or the best match we would find
(find-best-match ;;; from looking at the rest of the
sample ;;; tiles. Use pick-better-match
(rest tiles) ;;; to determine which one is better.
color-comparator)
color-comparator))))
(define (pick-better-match sample tile1 tile2 color-comparator)
(if (color-comparator sample (tile-color tile1) (tile-color tile2))
tile1
tile2))
We still need to figure out how to create the list of tiles. Suppose we start with a list of filenames of images and want to turn that into a list of bitmaps to use as the tiles. How can we break that into simpler problems?
If we have a function that can load one tile image, then all we need to do is apply that function to every filename in the list of image filenames.
We can do that with (map get-one-image image-names). The function map applies a function (the first parameter) to every element in a list. We use this to define a function that takes a list of image filenames, and produces a list of the corresponding bitmaps:
(define (load-images image-names)
(map get-one-image image-names))
Now, all we need are functions for getting a list of image filenames and
for getting one image. We could just create the list of images by hand,
but for a good photomosaic we need many images. So, we instead put all
the tile images in a directory and use a function that gets a list of
all files in a directory. DrScheme provides directory-list to
do that. So, (load-bitmaps (directory-list)) would evaluate to
a list of bitmaps for every file in the current directory. The actual
code provided is a bit more complicated since we want to handle
directories that contain files that are not images and we want the name
of the directory to be a parameter (instead of using the current
directory).
One way to display the photomosaic is to create a web page with all the tile images in the right places. The result of select-mosaic-tiles is a two-dimensional list of all the tile images in the photomosaic.
For example, suppose the best tiling for a 3x3 photomosaic (for now, we are just using names of colors for the tiles) is:
Then, select-mosaic-tiles would evaluate to:
red red red white white white blue blue blue
(("red" "red" "red")
("white" "white" "white")
("blue" "blue" "blue"))
We can display this using the divide-and-conquer approach: display the first row of images at the top, and then display the rest of the images below it. Displaying one row of images is similar: put the first image at the left of the screen, and then put the rest of the images to its right.
Our rough code is:
(define (display-tiles output-file tiles) (map display-one-row tiles))We define rough code for display-one-row similarly:
(define (display-one-row output-file row)
(map display-one-tile row))
The actual code is a little more complicated since we need to pass the
output-file and to produce good photomosaics we also need some
additional parameters (like the size of the tiles).
To produce web pages, we need to put some formatting codes before and after the tiles. (You shouldn't need to look at these codes.) So, we define procedures that print the necessary codes before and after the tiles (print-page-header and print-page-footer). The produce-tiles-page procedure first prints the page header, then displays all the tiles, and finally prints the page footer.
(define (make-photomosaic
master-image ;;; Filename for the "big" picture
tiles-directory ;;; Directory containing the tile images
tile-width tile-height ;;; Display width and height of the tiles
;;; (doesn't have to match actual size)
sample-width sample-height ;;; Sample width and height (each tile covers this size
;;; area in master)
output-filename ;;; Name of file to generate (.html)
color-comparator) ;;; Function for comparing colors
(produce-tiles-page
output-filename
(choose-tiles (get-one-image master-image)
(load-tiles tiles-directory)
sample-width sample-height
color-comparator)
tile-width tile-height))
We take parameters for the master image, directory containing the
tiles, tile width and height, sample width and height, the output
filename to generate, and the function to compare colors (which you
will write).
We then call produce-tiles-page with the output filename, the mosaic tiles (calculated using choose-tiles, and the tile width and height parameters.
Your function should look like,
(define (closer-color? ;;; The name of your function.
sample ;;; The average color of the rectangle you want to match.
color1 ;;; The average color of the first tile.
color2) ;;; The average color of the second tile.
;;; A Scheme expression that evaluates to #t if color1 is a better
;;; match for sample, and #f otherwise.
)
In addition to the standard arithmetic operators (+, *, -, /), comparison operators (<, >, =), provided procedures for manipulating colors (get-red, get-green and get-blue), some other procedures you may find useful include:
