3/4- Brainstorm Session with Classmates & Meeting with Dr. McVey

Brainstorm Session with Classmates

Some classmates heard me talk about my fitness function ideas and chimed in with their thoughts. I had already figured something better than the average color of a tile was needed, such as dividing a tile into four and then seeing the average color of each of those. A further idea that came up was dividing into 16, which would catch even more of the disparities or similarities. Either way, these are leaps and bounds more superior than the average color of a whole tile. For example, let's say there is a tile with brown at the top and blue at the bottom. If you take that approach, you'll compare with the average of brown and blue, which is neither color. If you take the more sophisticated approaches, the brown is caught as brown, and the blue is caught as blue, and the comparisons are that much more exact color-wise. The examples will only get more complex from there, such as a dog's leg in the upper-right-hand corner.

There was also the idea of using recursion only to divide a tile if needed. For example, if a tile is a part of a green bush, thereby being fully green, there's no point in dividing it up at all, or at least not beyond four. But if the complexity score of a tile (here possibly referring to the breakdown of percentages of each color in the tile) is such that there is diversity, further breakdowns will be needed. Perhaps this recursion could apply to each of the breakdowns of each tile as well.

Lastly, there was a bit about possibly changing the resolution of images into dimensions of powers of two, so it's easier to divide up. I'll think about this later.

Meeting with Dr. McVey

Dr. McVey cleared up an essential part of the process: a generation will consist of pictures, not individual tiles of a picture. Thus, selections, mutations, and cross-overs occur between pictures (which are composed of tiles). The algorithm selects some great pictures to move on and changes them to keep them diverse.

I think I also get how the fitness score fits within the process, but I could be a bit off. Let's say you start with five pictures as options (it's a small number for simplicity) and 12 tiles to choose from. Each picture begins with random tiles, some duplicated, some absent. Each picture (1) is compared with the final (2). How good is this one? How close is it to the final? This comparison is where the fitness function comes in. Each of the tiles of the picture compares with each of the tiles of the final (more on the method below), resulting in a fitness score for each of the 1 tiles. The higher the fitness score, the larger the difference between the 1 and the 2 tiles. Those all add up to the picture's fitness score, which is what we really care about, and then the primary process starts again.

For the tile comparison method, there are two main options. First, I could go pixel by pixel, which is much more exact, of course. The issue is the sheer amount of comparisons, which translates to tons of extra computational power. You also can't pre-process that information.

Second, I could compare averages of quadrants. Here I can pre-process because I'd go through the pixels once, store them into 1,4, or 16 averages (depending on my breakdowns), then I can just use those averages later when comparing. That means I only compare 1,4 or 16 averages rather than all the pixels, which is a lot less computing power. The tradeoff is it's much less exact than the first option.

I'll try both, just as I'll probably try multiple fitness functions.

Next Steps

I'll work on building the app skeleton and then outputting pictures on the screen. After that, I can figure out how to split the pictures into tiles.