Code: puzzle.manager

[pv33]

Get a functional puzzle manager.
This part is partially blocked by the lack of existence of a calibrated puzzle model.
To obtain one requires having the puzzle.parser.simple class functional in order to generate the calibrated puzzle model. Then new puzzle.board measurements could be checked against.

[pv33]

Builds on puzzle.parser.simple or even just puzzle.parser.fromLayers to generate the calibration part.

Instantiate a new puzzle.parser.simple with noneLayers and manager, then send in the same calibrated image. Should match the things just fine.

Note that this part requires for the puzzle.piece matching code to be functional. Thus, it is also blocked by some test scripts and issues related to the puzzle piece matching parts.

As an alternative, you could also do a color-based matcher since the objects are different colors. Just compute the average color in RGB space and compare. You can call is meanColor or something silly like that.

Anyhow, by this point, you should see how I am using classes and testing order to build out capability in a way that individual classes are fairly simple. Some could be coded up as one thing only instead of from a few simpler sub-classes, but they'd lost flexibility and create a more complete unit test pipeline.

In the end, this semi-explosion of classes will be beneficial and contribute to independent testing of multiple higher level components under controlled circumstances. That latter part is so important.

All code for each class should be fast to write. At least for someone expert in python. If it were me writing in Matlab, many of the classes would be functional by this point.