Single Image download from output Image collections (Image assembling plugin)

[mohamedOuladi]

Summary

Single Image download from output Image collections (created with the image assembling plugin) is not working properly.

What is the current bug behavior?

When the user downloads a single image from an image collection (created with the image assembling plugin), the downloaded image is not the output expected when opened with ImageJ's Bioformats plugin. However, when the user downloads the whole image collection as a zip archive, unzip it and then opens the images within with ImageJ's Bioformats plugin, the output images are correct (the expected output).

What is the expected correct behavior?

Downloading a single image should give the same image coming from the downloaded image collection archive.

Steps to reproduce

Download a single image from an image collection created with the image assembling plugin and open with ImageJ's Bioformats plugin.

[MyleneSimon]

After some investigation, it seems that this is more of an ImageJ/BioFormat importer issue, rather than a WIPP bug.

We were able to reproduce the bug using the following steps:

• download a single image from an image collection in WIPP
• the downloaded image will go to the default "Downloads" folder
• if an image with the same file name exists in this folder, the newly downloaded image will have a new file name similar to img_name (1).ome.tif
• using Import -> BioFormat in Fiji to open the image, the displayed image will have the size of the image selected, but with pixel values from the other img_name.ome.tif image that was present in the same folder, because BioFormat relies on the FileName tag in the metadata of the image
• if the downloaded image is placed in a separate folder, the correct image is opened

@Nicholas-Schaub I remember you talking about a similar issue depending on which plugin was used to generate the image, is that the issue you encountered?

Closing this issue for now, as from WIPP's perspective, population of metadata was correct, and download of requested image was correct as well.

[Nicholas-Schaub]

@MyleneSimon , we have had this problem in the past. I believe it is actually a problem with Bioformats. For some reason Bioformats uses the metadata id to load the metadata, but will actually grab the pixel information from the correct image. This means that if you have a file with a metadata id that matches a different file in the same folder, the metadata for the other file will be loaded but the pixel information for the correct file will be loaded for display. This also leads to odd behavior, for example if the mismatched files have different data types and sizes.

The issue I encountered had to do with downloading images before and after processing with a plugin. Some plugins do not change the id in the metadata, so when opening the output image from a plugin, it could have display issues.

[Nicholas-Schaub]

Basically to resolve this issue, every plugin should make sure to modify the Bioformats metadata. Bioformats will always use the data type in the metadata to load the pixel information, so if your output image will have a different data type than the input and the metadata is not modified, there will be problems loading the output image.