PS1 Comments

(The kindergartner has actually been tricked by an evil conspiracy between paint manufacturers and kindergarten teachers into thinking the primary subtractive colors are red, blue, and yellow, which is pretty close to magenta, cyan, and yellow, but not close enough to be able to make all the colors by mixing them in the right quantities. This is why the kindergartner isn't happy with just three paint colors, but insists of getting lots of colors. The primary colors is probably the first "scientific" thing the kindergartner is taught in school, so it is unfortunate that her education starts with being deceived and lied to. Alas, most children never recover from this.)

Fortunately, in this case, red and yellow are pretty close to magenta and yellow, so mixing red and yellow additively produces a color similar to orange. We can use the average-colors procedure defined in mosaic.rkt to produce orange by averaging the red and yellow colors (this requires passing in a list of the colors to average, which you hadn't seen for PS1, but should understand now):

   (define orange (average-colors (list red yellow)))

This makes a pretty good approximation of orange.

(define brighter?
   (lambda (color1 color2)
      (if (> (+ (get-red color1)
                (get-green color1)
                (get-blue color1))
              (+ (get-red color2)
                 (get-green color2)
                 (get-blue color2))
          true
          false)))

This works pretty well (and was enough to pass all the test cases), but we can do better. Fist, observe that the if expression is unnecessary! The > application already evaluates to a Boolean value, so (if b true false) is equivalent to the shorter and clearer expression b (but only in cases where b always evaluates to either true or false; as we saw in question 1h, the if expression works for predicate expressions of any value). So, a smaller and simpler brighter? definition would be:

(define brighter?
   (lambda (color1 color2)
      (> (+ (get-red color1) (get-green color1) (get-blue color1))
         (+ (get-red color2) (get-green color2) (get-blue color2)))))

This is better, but still could be improved. Note that there is a lot of duplication here, since we need to sum the red, green, and blue parts of both color1 and color2. Anytime there is a lot of duplicated code we should be thinking if there is a way to abstract the duplicated code to make our definition shorter and more versatile. Here, it makes better sense to define a brightness procedure and define brighter? using it:

(define brightness
   (lambda (color)
       (+ (get-red color) (get-green color) (get-blue color))))

(define brighter?
   (lambda (color1 color2)
      (> (brightness color1) (brightness color2)))

This has the advantage that if a cognitive scientist (I think we may have one or (twenty) two in this class) who has studied perception points out that the way human eyes perceive color does not view red, green, and blue as equally bright. This graph shows how the human eye absorbs different colors:

(from Robyn Owens' computer vision lecture)

(define brightness
   (lambda (color)
       (+ (* 0.299 (get-red color))
          (* 0.587 (get-green color))
          (* 0.114 (get-blue color)))))

Note that because we defined brighter? to use brightness, there is no need to change the definition of brighter? if someone comes up with a better brightness procedure.

(define (closer-color? sample color1 color2)
  (<
    (+ (abs (- (get-red color1) (get-red sample)))
       (abs (- (get-blue color1) (get-blue sample)))
       (abs (- (get-green color1) (get-green sample))))
    (+ (abs (- (get-red color2) (get-red sample)))
       (abs (- (get-blue color2) (get-blue sample)))
       (abs (- (get-green color2) (get-green sample))))))

As with the first brighter? definition, though, there is lots of duplicated code so we should be able to do better.

First, observe that the two subexpressions that are the operands of the < application are both computing essentially the same thing: the closeness between two colors. So, we should define a procedure that abstracts this:

(define color-difference
   (lambda (colora colorb)
      (+ (abs (- (get-red colora) (get-red colorb)))
         (abs (- (get-blue colora) (get-blue colorb)))
         (abs (- (get-green colora) (get-green colorb))))))

Then, we can define closer-color? as:

(define (closer-color? sample color1 color2)
   (< (color-difference color1 sample) (color-difference color2 sample)))

One advantage of this approach is that it makes it easy to change the way we measure color closeness. For example, using square instead of abs produces a slightly better color-difference metric:

(define color-difference
   (lambda (colora colorb)
      (+ (square (- (get-red colora) (get-red colorb)))
         (square (- (get-blue colora) (get-blue colorb)))
         (square (- (get-green colora) (get-green colorb))))))

If we thought we might want to try other metrics, we could even abstract the color difference function like this:

(define generic-color-difference
   (lambda (cf)
      (lambda (colora colorb)
         (+ (cf (- (get-red colora) (get-red colorb)))
            (cf (- (get-blue colora) (get-blue colorb)))
            (cf (- (get-green colora) (get-green colorb)))))))

(define (closer-color? sample color1 color2)
   (< ((generic-color-difference square) color1 sample) ((generic-color-difference square) color2 sample)))

Using square here now has the drawback that if you make a commercially valuable photomosaic this way you might get sued by Robert Silvers! His patent includes the following C code to describe the patented RGB RMS method:

/* This is a variation of RGB RMS error. The final square-root has been eliminated to */
/* speed up the process. We can do this because we only care about relative error. */
/* HSV RMS error or other matching systems could be used here, as long as the goal of */
/* finding source images that are visually similar to the portion of the target image */
/* under consideration is met. */
for(i = 0; i > size; i++) {
rt = (int) ((unsigned char)rmas[i] - (unsigned
char)image->r[i]);
gt = (int) ((unsigned char)gmas[i] - (unsigned char)
image->g[i];
bt = (int) ((unsigned char)bmas[i] - (unsigned
char)image->b[i];
result += (rt*rt+gt*gt+bt*bt);
}

This is actually how the code is formatted in the patent! Unlike most documents, and especially, unlike the code you write for cs1120, patents are written deliberately to be hard to understand. Reformatting the code and removing some of the C cruft for dealing with data types, it is essentially:

   rt = rmas[i] - image->r[i];
   gt = gmas[i] - image->g[i];
   bt = bmas[i] - image->b[i];
   result += (rt*rt + gt*gt + bt*bt);

You are not expected to know the C programming language, of course, but might still be able to guess that this is computing the differences in the red, green, and blue components of the tile and image, storing them in the variables rt, gt, and bt, and then computing the result as the sum of the squares of the color component differences.