Bug: Download projected image

[jburel]

• Import an image
• Project the image.
• The projected image cannot be downloaded since there is no fileset associated to it.

[mtbcarroll]

Indeed, it's neither an "FS image" nor is it archived,

omero=> select name, fileset, archived from image;
          name           | fileset | archived 
-------------------------+---------+----------
 IAGFP-Noc01_R3D.dv      |      55 | 
 IAGFP-Noc01_R3D_proj.dv |         | 
(2 rows)

An obvious question is, what is supposed to be downloadable for a projected image, and from where ought it come?

[jburel]

we generate a new pixels set so we should be able to access it and download like any other image.

[mtbcarroll]

Ah, I'd assumed "download" was an "original file" kind of thing and the export / save as options were the translators to other useful formats, and that the raw Pixels/ files weren't much use outside OMERO. A pixels set is usefully downloadable in a more direct form, maybe. I'll look into what's actually stored for this projection, that might be enlightening. (Assuming that the "download" isn't just meant to give the pre-projection file from which the projection was made.)

[mtbcarroll]

Well, there's an interesting zip archive:

omero=> select a.file from annotation a, imageannotationlink ial, image i
omero-> where a.id = ial.child and ial.parent = i.id and i.name like '%_proj%';
 file 
------
  168
(1 row)

$ unzip ~/var/omero/Files/168
Archive:  /Users/mark/var/omero/Files/168
  inflating: Batch_Image_Export.txt  
  inflating: IAGFP-Noc01_R3D_proj.dv_c00_z01_t01.png  
  inflating: IAGFP-Noc01_R3D_proj.dv_merged_z01_t01.png  

[mtbcarroll]

I wonder,

1. if download users should get the whole zip, or some subset of it
2. how to be sure that the right annotation is found: the Batch_Image_Export-related namespace may not be a sufficiently specific indicator, for instance if the user could also do other batch image exports on that projected image.

[jburel]

Let's discuss tomorrow.
You are looking at the wrong thing.
We have issues with all the scripts generating images (see testing list)
and the projection from ProjectionService (that the one related to that ticket)

[mtbcarroll]

Okay, I'll be interested to learn how to find the thing that should be downloaded. (-:

[jburel]

After discussion today,
The only "download" option for such image will be the download as OME-TIFF.
We do not want to misuse the FileSet concept (mainly for B-F)

Mark thanks for your investigation.

[jamoore]

Would a generalized getDownloader(preferredOrder = ["OME-TIFF", "FilesetZip", "ArchivedImage"])-style method solve some of this in the long-run?

[jburel]

That was the strategy we use in the OMERO gateway i.e. if not archived, return an OME-TIFF but this was confusing for users.
The following getDownloader(preferredOrder = ["FilesetZip", "ArchivedImage"]) will certainly reduce the code in the various gateways
since we have to do the check anyway.
This is not really related to that question.

The ticket can be closed.

[jamoore]

No veto there. If we want a "RFE: new API method" or whatever, feel free to open.

[jburel]

see #11692