Add TMA FOV validation functions for user sanity checking

[alex-l-kong]

What is the purpose of this PR?

Closes #16 (and closes #18). Users may need some guidance as to which FOVs are the most likeliest that need remapping. This includes:

1. User-proposed FOVs that are far away from their auto-generated FOV
2. User-proposed FOVs mapping to the same auto-generated FOV
3. User-proposed FOV names that don't match their corresponding auto-generated FOV names.

We want a way to display these to the user on the initial visualization, as well as update them on the fly when the user remaps FOVs.

How did you implement your changes

We allow the user to specify which combination of the 3 issues stated above they wish to validate in autolabel_tma_cores.ipynb. Each of these issues is handled in a separate validation function that builds a list of mappings that do not pass the specified tests. These non-passes will be displayed in a text box right above the slide image display.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[alex-l-kong]

NOTE: now that we're running a lot of tests for certain functions randomizing order, need to start moving away from simple != testing for randomization (the branch is failing again because of this, it'll happen more often than usual if we're running a double-digit amount of tests on these functions). I think the best way to handle this is to start using a random seed for these functions, although I'm open to other ideas.

[alex-l-kong]

More along the lines of setting consistent random seeds, looks like the pytest-randomly library may allow us to do this fairly seamlessly: https://github.com/pytest-dev/pytest-randomly.

[ngreenwald]

Looks good, minor changes only

[alex-l-kong]

After some thought, I've decided to do some major restructuring to the pipeline:

• assign_closest_fovs will now be a hidden call in tma_interactive_remap...this notebook cell was looking more and more unnecessary by the day and it'll help address the issue of the function being too involved. We also don't need an explicit manual_to_auto_map in the notebook if we're just going to read that in as mapping after the interactive remapping process anyway.
• We'll have assign_closest_fovs return the original manual_to_auto_map and a distance matrix (in microns) in numpy.ndarray or pandas.DataFrame format between each FOV. Having a lookup table for the distances between FOVs in microns will greatly reduce the number of conversion calls we'll need to make when remap_manual_to_auto_display is called. It also removes the need for a convert_pixels_to_microns function when recalculating distances on remap for validation purposes, preventing inconsistent results (due to floating point precision/rounding errors converting from microns to pixels and back won't yield the same results).

Let me know your thoughts @ngreenwald.

[ngreenwald]

Sure thing, if you think it'll simplify things go for it

[ngreenwald]

Nice, this is much more clear