surface template image alignment data for QC purpose

[ludovicbellier]

Description

So far in the CaImAn MSR tool on IDEAS, the only available QC information was related to the registered cells (registration yield, average footprint centroid distances and overlap...). Yet, MSR consists in 2 steps: aligning the cellsets (precisely, aligning the sets of footprints based on x/y shifts obtained from aligning the template images), and register aligned cells across sessions. And even if alignment fails miserably, there could still be registered cells as long as they pass the centroid distance and overlap criteria. In other words, only relying on registered cells-related metrics for QCing MSR is risky and can mask catastrophic alignment failures.

This PR surfaces 2 pieces of information pertaining to the alignment step of MSR: the aligned template for the 1st session, and the x/y shifts necessary to align said template and footprints. It does so for both optical flow and NoRMCorre piecewise rigid approaches.

Also, this PR implements max_shifts-adaptive overlaps and square ratio for patches:

• in the NoRMCorre approach to align templates, overlaps was hardcoded to [16, 16], which led (for some complex reason) to nan-only aligned patches when the needed shift to properly align templates was over 8 pixels; x/y shifts could still be computed and applied to the footprints, so MSR did work fine, but the aligned template was nan-only and couldn't be used to QC alignment. In this PR, overlaps is now set as the maximum between max_shifts * 2 and strides / 4. With strides being defined as a quarter of the smaller FoV dimension (e.g., for a (640, 400)-shaped FoV, strides would be 100), this adaptive overlaps kicks in for max_shifts > 12.5: if max_shifts = 10 (defaults), overlaps would be 25 (strides / 4), but if max_shifts = 64 (pixels), overlaps would be 128 (max_shifts * 2). Any value below max_shifts * 2 leads to sparse aligned template (again, for some complex reason around this line in the CaImAn motion correction code), and impairs alignment QCing.
• also in the NoRMCorre approach, FoV is cut into patches, based on strides and overlaps parameters; these 2 params were set based on the FoV dimensions, so non-square FoVs led to non-squre patches (e.g., (640, 400) FoVs led to (160, 100) patches). As the FoV is isotropic (both x and y axis have the same spatial resolution, it just happens that for some movies we record more data on one axis than on the other), I think it makes more sense to have square-ratio patches, which I implemented in this PR.

TL;DR: we need this PR for QCing the alignment step of CaImAn MSR