HCS and handling of row/column index keys

[sbesson]

See original report from @pwalczysko in #31 (comment)_

Index keys for the well rows/columns were initially introduced in glencoesoftware/bioformats2raw#91 and first released in the version 0.3.0 of bioformats2raw.

These keys have been formalized and specified upstream in the OME-NGFF 0.4 specification - see https://ngff.openmicroscopy.org/0.4/#plate-md. As part of this specification, they have been renamed as rowIndex and columnIndex to match the naming style for new keys.

In both cases, these indices are expected to be integers.

ZarrReader/src/loci/formats/in/ZarrReader.java

Lines 634 to 652 in 649a60e

	String wellCol = (String) well.get("column_index");
	String wellRow = (String) well.get("row_index");
	String well_id = MetadataTools.createLSID("Well", wellCount);
	store.setWellID(well_id, 0, w);
	String[] parts = wellPath.split("/");
	if (wellRow == null || wellRow.isEmpty()) {
	wellRow = parts[parts.length - 2];
	}
	if (wellCol == null || wellCol.isEmpty()) {
	wellCol = parts[parts.length - 1];
	}
	int rowIndex = "ABCDEFGHIJKLMNOPQRSTUVWXYZ".indexOf(wellRow.toUpperCase());
	if (rowIndex == -1) {
	rowIndex = Integer.parseInt(wellRow);
	}
	int colIndex = "ABCDEFGHIJKLMNOPQRSTUVWXYZ".indexOf(wellCol.toUpperCase());
	if (colIndex == -1) {
	colIndex = Integer.parseInt(wellCol);
	}

currently handles legacy keys and casts them as strings. This leads to exceptions when dealing with HCS generated with bioformats2raw 0.4.0.

For the OME-NGFF 0.4.0 specification, we should at minimum read the rowIndex/columnIndex keys as Integer.

This leaves a few open questions related to the support of old and new datasets:

• should the column_index/row_index keys still be parsed to handle OME-NGFF 0.2 datasets created by `bioformats2raw 0.3.x and 0.4.x?
• for OME-NGFF 0.4 plates, should we keep the fallback mechanism parsing the well paths be maintained or should the reader on the absence of rowIndex and/or columnIndex since these fields are required.

The last item more generally raises the question of how lenient vs strictly compliant the reader should be. If there is a use case for both behaviors, this is possible something worth putting under an option.

[dgault]

With the latest commits on #31, the reader should now handle 3 different scenarios for the row and column indexes:

• parsing rowIndex/columnIndex for NGFF v0.4 data
• parsing column_index/row_index as per BF2raw 0.3 and 0.4
• fallback to parsing the data out of the path