Limit scale of adjustments for `microfluidic_chip` button/chamber finding.

[palmhjell]

For a MITOMI device, chambers spacing is near-perfectly regular, with the main deviations coming from (1) imperfect staging of the slide (e.g., giving rotation) and (2) stitching errors. These are generally very slight issues with only very small local adjustments needed from chamber to chamber, and mostly handled by pipeline arguments.

Right now, the protocol allows larger-than-reasonable adjustments to chambers (often thinking that part of the neck or sandwich is part of the chamber), see:

where the chambers would have been found almost perfectly (yay!) if no (or far smaller) adjustments were made (boo).

It would be nice if (1) there were an argument to limit the scale of the adjustments made during button/chamber finding, and (2) if these adjustments could be limited locally (i.e., only i pixels from the center of the surrounding chambers), since chamber-to-chamber deviations are far smaller than global deviations across a chip.

[palmhjell]

(only somewhat related, but I much prefer looking at the fg outline rather than having the full circle filled, which is currently the default when viewing the results in napari.)

[k-rl]

As discussed in person you're actually seeing chambers that didn't go through a final adjustment step when they are misaligned. This can be because either

1. that chamber is set to be a blank on your pinlist in which case magnify won't try to make final adjustments because you told it that it shouldn't expect to be able to find anything in that chamber
2. Your chamber is irregular in some way and therefore isn't meeting the minimum roundness requirement you've set so no suitable circles are found to make an additional adjustment with.

Regarding the comment about the fg outline I agree with you that it's better to look at than the filled circled. I tested it out as a default but unfortunately napari is very slow to render circle outlines for some reason which makes it harder to swap between timesteps. For now I'll keep the current default for performance reasons but will plan to change it if it looks like newer versions of napari won't suffer from the performance hit.

[palmhjell]

Re-opening this: suggest to add a third step in the circle-finding protocol in which the unmoved circles from the second step are adjusted to be on the grid of their now-moved neighbors.