findPoints() distinct from findPointMatches()

[jywarren]

Building on #2 --

Hi @rexagod -- is there another method for findPoints() (roughly?)?

And, once an image is matched with this, is there a stored "analyzed image" object in memory that we could store so that people could save computation time by storing the points in a single image, so that if they want to do another match it'd run faster?

So for example, can the process be broken up into:

var matcher = Matcher.new(imgA, imgB, options, callbackFn); // doing it all together

// versus one step at a time:

// find points for A and B:
var imageAPoints = var matcher = Matcher.findPoints(imgB);
var imageBPoints = var matcher = Matcher.findPoints(imgA);

// match between A and B:
var matchesAB = Matcher.findPoints(imageAPoints, imageBPoints);

// now match between A and C:
var imageCPoints = var matcher = Matcher.findPoints(imgC);
var matchesAC = Matcher.findPoints(imageAPoints, imageCPoints);

Does this make sense? Thanks!

[rexagod]

@jywarren I believe the cache mechanism serves this exact purpose, i.e., if the user decides to run the match again it will be 100% instantaneous, also the caching is automated for different image imputs so the user doesn't have to explicitly specify "storing" the outputs in their code for different pair of images.

The overhead is, as I described yesterday, reduced from ~7000 frames to a maximum of 15 frames (benchmarked on Windows XP using BrowserStack), which is comparatively negligible (99.8% lesser frames than before) in terms of performance. Also, just to mention, the users can pass a caching: false option to prevent caching, if they want to for some reason. Please refer below for visuals.

Without caching (cleared localStorage before running in the console, takes ~1 second on first iteration):

With caching (instantaneous, second iteration onwards):

PS. Just mentioning that currently the module implements findPoints() and findPointMatches()as already resolved values (corners and matches) which can be accessed through utils object initialized by the constructor. But let me know if you want to shift this to function calls with the same name and I'll get to it!

Thanks!

[jywarren]

Actually, I just want to know if they can be run separately by downstream code - and if this is well documented in the README, with their accepted parameters and options? That'd be really great, thanks!

[jywarren]

And I'd really like if you could expose them with those names, because I don't see anything in the README that is as understandable as those names, that helps people know the steps in the process or how to use them. Thanks, @rexagod! This will really make the library much more understandable to people, you know? Something like:

The process of generating matches takes two phases; `finding` and `matching`. `finding`, 
or identifying interest points in an image, is run with the `____.findPoints()` method, which accepts
 2 parameters. It outputs a `points` object, which can be stored for later use. `finding` will take a 
few hundred milliseconds for a ___ by ____ pixel image.

See this example:

The output `points` is in the following format:

By setting the `limit` option, you can request a maximum number of points, which will make the
 algorithm run faster. See this example:

...

And the same for the matching step!

`matching` is done with the ______ function, which accepts as parameters two `points` objects. 
It returns a `matches` object with the following format:



It runs faster/slower than the point `finding` step.... (or something)

See how this type of documentation can walk people through a real usage scenario for your code, with examples, explanations, and code snippets? How it explains how to use the lib to someone who just knows they have 2 images and want to generate matches, and tune/optimize themselves?

Please try to produce some documentation that follows this format, and has naming conventions that are really understandable -- you can have deeper explanations of the algorithms you use further down in the README, but we really need to show the basics of usage in simple, functional terms, and show people how to put this code to work!

Thanks @rexagod !!!! This will be great! 🎉

[jywarren]

Hi @rexagod can you provide an update on progress here and mark the lines of code where this is happening? Thanks!

[rexagod]

@jywarren The "points" are capped at 500 while the "matchedPoints" are a subset of those. This generation of "points" is almost instantaneous (owing to the recent changes in the lib) and limiting the points doesn't bring any substantial performance improvement since we're already maxed out on optimizations. But this could be incorporated into the lib from a UX POV, I guess.

What do you say?

[rexagod]

Hi @rexagod can you provide an update on progress here and mark the lines of code where this is happening? Thanks!

On it!

[jywarren]

Great! Just be sure to open a PR which contains the changes that fulfill this issue -- all together! Thanks!

[rexagod]

Closed in favor of #10