As noted elsewhere, the program does pick up flaws in images (such as the bleeding in the Princeton logo). This suggests that it works best with less detailed, "cleaner" images. The following failed mosaics are also good indicators of this inadequacy.

There's also this strange inconsistency in the new algorithm. It's supposed to calculate color differences for each of the 16 subtiles and add them up to one tile-wide color difference. However, when I did that, it didn't work at all. It preferred that the color difference variable just be reset for every subtile. This seems to have worked for the Princeton seal and Marilyn and somewhat for the Commencement picture, but not the tiger. Theoretically, it shouldn't work at all or at least not as well as it did. These errors are probably due to some type errors earlier in the calculation (int vs. float or something of the sort).

Speaking of type errors, I realize now that they could be responsible for much of the first algorithm's inaccuracy. I did not catch some of them until a day or two before the end of the project, and then I was able to create the seal and Marilyn with the second algorithm.

One major flaw is the amount of memory the program uses (especially with reference to the second algorithm). After all, if there are L number of images in the library, it makes an array with 16 allocations for each color (there being three colors) and one more for the string containing the filename. That's an array of 49 * L elements. It also creates an array for a target with T tiles with 48 * T elements. Realize that T and L are most likely on the order of 10^3. As if that weren't enough, compare() then creates an array with 3 (QoF, tile number, filename) * L * T elements. This problem is further exacerbated by subdivide(), which has a minimum restriction but not a maximum. If it resulted in a target subdivided into 15000 tiles or more, the program would run out of memory and crash.

*Note: (I realize that) This is not a complete list of the flaws in my program.