After talking to my mentor, I have decided to rethink some things. Before I even start, I needed to sit down and re-evaluate some goals and how my code is built, as well as how the chi-square will fit into it.

Right now I have an excellent blob to matrix function, splitting the blob into a 6×6 square.

Analyzing these now needs to happen using a simplified chi-squared metric.

My plan for tackling this is as follows:

### Program – Explained

For every blob in the image (except for blobs considered tiny!! Which is not yet implemented!!!) the program will go through and give them a “score” using a simplified version of the chi-squared statistic.

The program comes up with this score by comparing two graphs of a shape, and counting every pixel off in the 6*6 grid. The score is then given as 1/((pixels off) + 1). Where 1/1 or 1 would be considered a “perfect” score. For every pixel off, the score goes down.

The program will test the blobs against the shapes presented to it, currently stored as enums as LINE, SQUARE, CIRCLE, and TRIANGLE.

For example, when given a obviously perfect square, the program will rate it as follows:

square : 1.0

line: 0.0322

circle: 0.2

triangle: 0.0588

Where the closest shape this this shape is clearly a square, since it is a “perfect” fit for it.

The program is supposed to take the highest value out of these, and count the blob as a “square” because of it.

However, the problem I am running into is as follows:

Obviously I need to address this problem. Similarly, to not lag the entire thing down, I need to make sure that the program will not do any of this on “tiny” blobs.

### Bug Fixes and Perfecting the program

Thanks to my adviser, we now have a program that can fairly accurately identify squares, circles, and lines. However, it still struggles with triangles.

As I have discovered, this is because I put the “expected” grid of the triangle in sideways. After an easy fix, it now counts 4 triangles, the arrow and three actual triangles.

After some more testing I have figured out that it is labeling all the shapes mildly incorrectly. Here is an illustration below of the programs true functionality.

I theorize that to make this work better, it needs the old implementation of the definition of lines in place: where it count empty spaces, and more stringent definition of squares: where they have to have corners filled in, to obtain better functionality.

After playing with line analysis it now works much better, however, incorrectly identifying way to many object as squares is still a problem.

However, hopefully “twisting” shapes will allow them to fit into other categories of shapes without them being considered squares.

### Rotating Shapes

Rotating shapes appears to be a struggle, as the shapes rotation appears imperfect at best.

Testing the implementation on a triangle yields the following results:

### Overdue

Everyone is going home for the Winter Break and our college is closing the dorms etc. Since we have not met our goals before the end of the semester we will be working on a whatever-we-can basis over break.

Ultimately my goal is still to fix this analysis, and get a crude aesthetic metric done. I feel like I am incredibly close, and will continue this into next week.

The blog as such will update as usual, but a formal winter break notice will be added in the future when goals have been met and work ceases.