naming of images in omero

[pwalczysko]

See https://github.com/ome/ZarrReader/pull/31#issuecomment-1113459183 and https://github.com/ome/ZarrReader/pull/31#issuecomment-1113477796 for background.

First suggestion would be:

1. Any system which propagates the original filename from the starting format is acceptable.
2. System which alters the filenames in the process is acceptable only if additions or logical replacements are made (such as extension ome.zarr replaces ome.tiff, and the name will be longer because... (cannot imagine why), but the original string from the starting format should be there in full

cc @sbesson

For what it is worth, the system I am using in testing is actually encapsulating the name of the original file in the name of the top folder, such as blah.ome.tiff will become blah.ome.zarr/ folder as produced by bf2raw. It might be an option to simply harvest this folder name, but possibly too short-sighted, as it might not work on S3 ?

[pwalczysko]

@joshmoore @dgault

[sbesson]

A few thoughts

• in typical conversion worfklow, I don't think the original filename will ever be exactly preserved. It is rather expected to changes the user will run some conversion of form conver_command foo.ext1 foo.ext2.
• part of the naming issue arises from the fact the naming images at import time is derived from the filename of the first file in the fileset - see https://github.com/ome/design/issues/57 for more technical details)
• this assumption is generally acceptable fon most non-HCS file formats which will either be single file or typically have a master file into whose name some minimal metadata i embedded
• as per the specification, the filenames in a Zarr dataset follow specific conventions (.zarray/.zgroup or 0/1/2...) which rules out the usage of custom naming
• image names can be overwritten at import time e.g. using omero import -n NAME but my understanding of this issue that we are trying to solve the problem of the default naming

At least from my side, there are two possible sources of truth:

• the Image.name key in the metadata: main advantage of this is that it offers an identical correspondence between the original and the converted data. Supporting it requires to come back to the implementation proposal in https://github.com/ome/design/issues/57
• the name of the Zarr folder e.g. blah.ome.zarr which we can reasonably expect to be named similarly to the original data. In this case, the issue is that only the filename is retained. Should there be either some specific handling when using this reader? Or use/defined a different API allowing to retrieve this metadata?

In terms of timeline, the current progression is to target an OMERO.server release including this reader to start supporting and gaining experience on OME-NGFF import. Does anyone feel this issue should be elevated as a blocker that we need to address? And/or would a new paragraph in the limitations section of the OMERO documentation be sufficient?

[joshmoore]

• the name of the Zarr folder e.g. blah.ome.zarr which we can reasonably expect to be named similarly to the original data.

Perhaps this is dependent on what's in the top-level .zattrs? Three current cases are: plain image, HCS, or bioformats2raw series. Your statement certainly makes sense for the first of these.