Hi Damir,
David is on leave this week so I will follow up as best as I can.
Thanks for all the information and big thumbs up for the workaround. If the tag 305 is already defined, overriding it with the expected string from the
ScanR reader should be sufficient to have TIFF files listed in the reader used files.
On the `metadata.ome.xml` issue, this file is indeed not included in the ScanR fileset, flagged as an separate import candidate and imported separately as a ghost multi-image fileset (see below for details). Removing the file certainly works. Alternatively, if using the command-line import, I would expect the advanced --exclude option to work as follows:
- Code: Select all
bin/omero import /path/to/ScanR --exclude=metadata.ome.xml
Generally, very glad to hear that Olympus ScanR people are evolving their stored data to use open formats. I understand the attempt is to store it as a
multi-file OME-TIFF with a companion file containing the metadata.
Below are a couple of thoughts from our side on the current status/limitations based on the sample fileset you uploaded:
- the OME-XML in the OME-XML file and the OME-TIFF headers are all fully valid according to the specification
- although syntactically valid, the XML header only defines a list of images but contains no information about the SPW structure
- assuming the intention is to create a companion file as every TIFF file refers to this file using the BinaryOnly, the companion extension must be `*.companion.ome` as per the specification.
At the moment,`metadata.ome.xml` is effectively treated and imported as an OME-XML file defining multiple images with no SPW structure leading to your ghost images. If this file was renamed `metadata.companion.ome` then I would expect it would be considered as an OME-TIFF fileset, that it should be imported alongside the corresponding TIFF files and that each imported image would contain the real pixel data. However, it would still lack the SPW structure as mentioned in my comment above.
Trying to move forward, please let us know if generating new
OME-TIFF samples describing the expected structure would help. In all cases, if the Olympus ScanR folks want to contact us to get more information engage developer discussion, please feel free to redirect them to the public community resources.
Best,
Sebastien