Fix image ROI reference population in Zeiss LSM and MIAS readers

[sbesson]

See #4394 and the failures reported in #4394 (comment)

When populating the OME metadata via setImageRoiRef, the Zeiss LSM and MIAS reader currently make use of the same index for the ROIRef as the ROI index. For multi-series, this means the setters are typically called as:

setImageROIRef("ROI:0",0,0);
setImageROIRef("ROI:1",0,1);
setImageROIRef("ROI:2",0,2);
setImageROIRef("ROI:3",1,3);
setImageROIRef("ROI:4",1,4);
setImageROIRef("ROI:5",1,5);

The sequence above was working with the current ome-xml implementation which was largely ignoring the roiRefIndex in setImageROIRef and using the order of the calls. With the changes proposed in ome/ome-model#226 and released in org.openmicroscopy:ome-xml:6.5.2 the index is now taken into account.

This change updates the readers to separate the roiIndex from the roiRefIndex and ensure each series starts with index 0.

Together with #4394, I expect this should address the failures in mias and zeiss-lsm although we likely still want to fix the underlying OME-XML library to support the scenario above which has been functional for years - see ome/ome-model#229.

[melissalinkert]

I think this should be initialized to the existing ROI ref count for the relevant Image (with index well). There can be multiple analysis files for the same well, e.g. one *detail.txt and one *AllModesOverlay.tif per channel.

[melissalinkert]

I'm not sure this is quite right. parseOverlays can be called multiple times per series, which would mean that roiRefIndex starts at 0 for every call, potentially overwriting previous references that were set on the same series. Using the existing ROI ref count for Image index i might be the easiest?

[sbesson]

0a8f829 is one way to address this by defining a transient roiRefIndex and resetting it to 0 for each series before the calls to parseOverlays. Is that what you were thinking of?

[sbesson]

After re-reading carefully the MIASReader logic, I was reminded of the following logic

bioformats/components/formats-gpl/src/loci/formats/in/MIASReader.java

Lines 1160 to 1170 in eb8fd30

	public void parseMasks(MetadataStore overlayStore)
	throws FormatException, IOException
	{
	boolean originalMaskParsing = parseMasks;
	int roi = 0;
	parseMasks = true;
	for (AnalysisFile roiFile : roiFiles) {
	roi += parseMasks(overlayStore, roiFile.well, roi, roiFile.filename);
	}
	parseMasks = originalMaskParsing;
	}

which was truly designed for OMERO imports and consumed in https://github.com/ome/omero-blitz/blob/5bf40c91b650586f4fdad4eb8827e682cc4eb683/src/main/java/ome/services/blitz/repo/ManagedImportRequestI.java#L895-L910

The MIAS ROI handling will require more careful attention including some validation win OMERO. To avoid creating a bottleneck, I am proposing the following progression:

• close this PR
• review if OMEXMLMetadata: prevent IndexOutOfBoundsException when setting references ome-model#229 alone suffices to fix all repository failures initially reported in Bump org.openmicroscopy:ome-model from 6.5.1 to 6.5.3 #4394 (comment)
• open a follow-up PR updating the Image ROI reference indexing in Zeiss LSM reader
• investigate separately the MIAS ROI parsing both using Bio-Formats command-line tools and OMERO and test the impact of ROI reference indexing changes.