Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating : puzzle piece state and feature descriptor #40

Open
pv33 opened this issue Oct 20, 2023 · 2 comments
Open

Updating : puzzle piece state and feature descriptor #40

pv33 opened this issue Oct 20, 2023 · 2 comments
Labels
documentation Improvements or additions to documentation

Comments

@pv33
Copy link
Member

pv33 commented Oct 20, 2023

Options

The feature descriptor consists of information pulled from the piece state. When performing data association, what needs to change/be updated? We have the following options regarding the original template piece:

  1. Puzzle piece raw data remains fixed.
  2. Puzzle piece raw data is overwritten.
  3. Puzzle piece raw data is blended / merged / averaged / etc.

We also have the following options regarding the feature descriptor:

  1. Keep original feature vector.
  2. Replace original feature vector.
  3. Blend feature vectors somehow (up to feature vector format I suppose).
  4. Recalculate feature vector (usually after blending raw data).

Ideal for Puzzle

Ideally we would have the original template, the latest matched template, and continued frame to frame matching with the latest matched that is ultimately associated to the original template.

That has a solution to latest association, plus a latest to current association. The association to the solution is for knowing where to place the pieces. The association of latest to current is to keep track of where things are more generally and how they move around. Moved is indirect work or direct work? Move achieves progress or not in terms of puzzle solving?

Solution Board

Solution piece correspondence would update feature vector but not original source data. It would definitely update the labels. It would be aware of "label constancy" (new things given high number past current labels). That means also checking for non-associated and having some kind of new piece label function.

@pv33
Copy link
Member Author

pv33 commented Oct 20, 2023

Note: Only the location is pulled out from the PuzzleTemplate information into a separate member variable in Template. Seems like it might be OK as long as Template does the right thing. The right thing may be established by a flag per above discussion.

@pv33
Copy link
Member Author

pv33 commented Oct 26, 2023

Resolution

A board has a flag to determine whether it will apply updates to its pieces or simply associate with the measurement.

Pieces have their own update function that establishes how to update their content. The member function will recurse to feature descriptor updating.

Not entirely sure that it is correct, but the current approach generates the associations, pushes new feature vector to estimate, and then pushes labels of estimate to the measurement. Plotting the measurement gives the current state. Plotting the estimate will give the original/source state. How proper is this? May ultimately need estimate to be updated. Rolling with code as is until I get a better grasp on the API.

For different properties, will need to overload the puzzle piece class (create a hierarchy of implementations).
Another option is to add in an update descriptor / configuration parameter for simple cases (not done, but could be). This kind of parameter would enrich the board level parameter. Keep this in mind too.

@pv33 pv33 added the documentation Improvements or additions to documentation label Oct 26, 2023
@pv33 pv33 changed the title puzzle piece state and feature descriptor Updating : puzzle piece state and feature descriptor Oct 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

1 participant