Open pwalczysko opened 2 years ago
@joshmoore @dgault
A few thoughts
conver_command foo.ext1 foo.ext2
..zarray/.zgroup
or 0/1/2...
) which rules out the usage of custom namingomero import -n NAME
but my understanding of this issue that we are trying to solve the problem of the default namingAt least from my side, there are two possible sources of truth:
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/57blah.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?
- 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.
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:
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 becomeblah.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 ?