Closed pv33 closed 2 years ago
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.
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 newpuzzle.board
measurements could be checked against.