Structural change on the piece.matcher

[Uio96]

Previously, puzzle.piece.matcher has a template parent class. The original process is to construct a matcher instance from a puzzle piece, then compare it with others.

I think it is better to remove this inherentence but instead turn the matcher into a class with two puzzle pieces input and then have a comparison. It is easier to understand its functionality and more user-friendly. I have modified it in 83cc5cca431d843a2e81cb55201fe6a0307106aa.

[pv33]

@Uio96 I disagree 100%.

You see, each piece class for the actual use will have its own way of creating a puzzle piece signature. Thus, that particular class should also have the comparator. Ripping the descriptor and the comparator from the puzzle piece seems really awkward. Ripping out only one and not the other seems even worse.

I don't know what is informing this decision. Please provide functionality evidence for why this makes sense.

I also think that the revised approach loses flexibility. Please explain how it improves flexibility.

[Uio96]

@Uio96 I disagree 100%.

You see, each piece class for the actual use will have its own way of creating a puzzle piece signature. Thus, that particular class should also have the comparator. Ripping the descriptor and the comparator from the puzzle piece seems really awkward. Ripping out only one and not the other seems even worse.

I don't know what is informing this decision. Please provide functionality evidence for why this makes sense.

I also think that the revised approach loses flexibility. Please explain how it improves flexibility.

Here is our original implementation:

template->matcher->matchSimilar/matchDifferent->moments

My plan is to separate puzzle pieces and their feature descriptors & matcher. So it would be like:

puzzle piece (raw data/processed data): template->regular

feature signature and matcher: matcher->matchSimilar/matchDifferent->moments/edge

I think it is a better idea. Here are my thoughts:

I consider puzzle.piece.template as the most basic template for all the puzzle pieces, which saves the most general information like location/contour/mask/color, etc. Then some particular pieces may have more specific descriptions. For example, the regular piece has four edges. It can save the four segmented edges and their types (flat/in/out). So I create a subclass for it, puzzle.piece.template-> puzzle.piece.regular.

I plan to put the feature signature and matcher together (The current implementation is not fully developed yet, for example, I need to move the edge feature extraction part from puzzle.piece.regular to puzzle.piece.edge). I think the feature descriptor & matcher do not have to be strictly connected to either puzzle.piece.template or puzzle.piece.regular. For example, puzzle.piece.moments is a matcher (including moments feature extraction and comparison), it can be used for both puzzle.piece.template and puzzle.piece.regular. puzzle.piece.edge is another matcher, which computes shape features/color features. It does not have to be just for puzzle.piece.regular but instead, some other special pieces can use that for comparison as well.

Since 1) the puzzle piece descriptor and 2) the feature descriptor and matcher are separate, I think it is more flexible.

[pv33]

Cannot close until the final version is properly explained here. I do not believe that the above comments reflect what we discussed today. Please explain final version by explaining class structure and what contains what, plus how processing will occur. What class has access to what data and how is it used. @Uio96

[Uio96]

Here is the current version:

template->regular: save raw data/processed data(e.g., location/contour/mask/color)

matcher->matchSimilar/matchDifferent->moments/edge: signature extraction function(e.g., Hu moments/color feature) and comparison function (some distance functions: e.g., L2/L1)

Each manager instance will be assigned a matcher instance. Then the manager will use the matcher to compute signatures and use that to have a pairwise comparison between pieces in the estimated board and the solution board.