Dealing with regional spots close together which should be kept and used, but as 1 single ROI

[vreuter]

⚠️ -- beware of interaction with #237

To combat the problem of proximal regional spots that should be retained being used as 2 separate ROIs rather than 1, we can merge the ROIs after the detection. Discussed w/ @TLSteinacker , and we have some planning for this...

• Regions from retained proximal ROIs (not excluded due to their proximity) should be merged, with the ROI redefined by the centroid-of-centroids, the centroids being those of the overlapping ROIs.
• Visualisation of both pre- and post-merge data (region boxes and discard reason annotation(s)) should be possible
• ROI centroid only, not ROI size, should change by merger
• Extent of overlap required for merge should be configurable
• When configurable, extent of merge required for overlap can be specified differently for cases of same-barcode vs. different-barcode overlap/proximity
• Same-timepoint spots should be considered for merge first, then different-timepoint ones afterward.
• Section declaring merge strategy should have these properties regarding its presence in config...
  • required when doing no proximity-based filtering (i.e., for now setting the minimum interspot distance to 0, perhaps some other clearer mechanism to be implemented)
  • prohibited when filtering out any pair of proximal spots ("trivial" grouping)
  • optional otherwise
• Section declaring merge strategy should be required, as a mapping (JSON object) bound to key roi_merge_strategy, and it should have the following properties:
  • auto_merge_dilation: real number >= 1, specifying how much to "dilate" each ROI for overlap consideration of other ROIs from the same timepoint, always required (because same-timepoint proximal spots will always be considered for overlap and merge)
  • allo_merge_dilation: real number >= 1, specifying how much to "dilate" each ROI for overlap consideration of other ROIs from other timepoints. we may want to consider requiring that this is at least as great as auto_merge_dilation, to ensure a user hasn't mixed up these values, as I'd anticipate that this would always want to be set at least as great as the auto_... counterpart. Thoughts, @TLSteinacker ? This is to be required if the regionGrouping is such that there's no filtering (i.e., minimum separation of 0, or some yet-to-be-determined other specification). This is to be prohibited if the region grouping is "trivial"
  • allo_merge_groups: a list-of-lists, like the regionGrouping groups value, specifying the groups of timepoints that are allowed to have their spot ROIs merge. The state of requiring/prohibiting/allowing this is that same as for allo_merge_dilation.
  • There's no requirement on the structure between / among groups, but within each group there should be no repeats, and any timepoint used in this section should correspond to a regional imaging round from the imagingRounds section of the config.

there would also be another relation that should hold in the config: a) if the proximity filter is permissive anything grouped together for merge should be grouped together for (protection from) filtration, but not necessarily vice-versa (i.e., don't necessarily merge what's permitted to be close together) b) if the proximity filter is prohibitive, anything grouped together for filtration must not be grouped together for merge, but not necessarily vice-verse (i.e., don't necessarily merge what's permitted to be close together)

Note that these two properties converge on the same absence of implication (don't necessarily merge what's permitted to be close together), which accords with the idea that merging the ROIs is a stronger/more specific thing than simply permitting them to be close together.

[vreuter]

Related: #260

[vreuter]

Related: #237

[vreuter]

Supersedes: #234

[vreuter]

Related: #228

[TLSteinacker]

Thanks for this really clear summary!!

regarding the real number >= 1, I agree with you that allo_merge_dilation should at least be as big as allo_merge_dilation.