Download OME-TIFF button runs Batch_Image_Export. See #8791

[will-moore]

Also moved the 'Archived Files' download button into the
same dropdown menu, and added a JPEG option (same as Insight).

This is probably not ready to merge just now, I just wanted others to have a look for feedback etc.

To test, (need to Archive Files on import) try downloading Archived files and export OME-Tiff via "Download" button in right panel of an Image.

I'm planning to have a "Confirm" dialog open for both the "Download Original File" and "Export OME-TIFF" options, to explain to the user what's happening. Both operations can take several seconds or longer, so they need to know what's happening.

Questions:

• When we download OME-TIFF (it's an attachment on the image) do we delete it from the Image? Could ask the same question for any attachment generated by script. If NOT, it's still taking up space (and becomes out of date with current annotations etc).
• If the user chooses to export OME-TIFF a second time, do we automatically overwrite any existing OME-TIFF attachments to the image (probably should).

[manics]

Download Archived file works, so does JPEG.

Clicking on OME-TIFF the first time opens the Activities list immediately but there's no sign of the export script running, even after waiting. Clicking it a second time seems to trigger the script, however the activities "in progress" icon never seems to change to completed, but refreshing the page shows that the OME-TIFF attachments have been created.

The behaviour is inconsistent:

• Archived file downloads the file
• JPEG opens in a new window
• OME-TIFF creates an attachment but doesn't open/download
• In read-only groups the OME-TIFF isn't an attachment

How about forcing JPEGs to download with an appropriate http header?
What's the reason for showing the OME-TIFF as an attachment? If it's to avoid having to rerun the script how about caching the TIFF but not showing it as an attachment, instead just download if if it exists or if the metadata has changed re-run the script and download. This also takes care of file space since you can delete old files when necessary.

What does everyone else think?

[manics]

I like the latest changes. Would still benefit from someone else having a look.

[jburel]

@will-moore:

• Create an OME-TIFF
• Delete it
• Go back and click on OME-TIFF
• The dialog box indicates that I have already an OME TIFF.
• Text could be improved e.g. 1 minutes.
• Click Download, Error page.

[jburel]

@will-moore:

• Click on info button takes time to load
• From time to time, animated icon does not spin.
• A refresh button post export will be nice.

[jburel]

@will-moore:

• Dialog to create OME-TIFF
  • I don't think given the time when the OME-TIFF was created is necessary. Especially if not correct. I will replace it
    with " or Download the OME-TIFF previously created" or something like that
  • Not a big fan of the term. "Prepare" sounds like a cooking recipe. I will use Create
  • The term "Prepare" is used then in the activity dialog, the Term "Export" is used. This is confusing+technically no export happens
• Since you do not have a wait to retrieve FileAnnotation, For OME-TIFF I will only have the delete option not the remove one

No download when no ome-tiff attached. Working

[joshmoore]

@will-moore, is this dependent on ome/omero-scripts#9?

[jburel]

@joshmoore: related for the action i.e. creation of the OME-TIFF but other UI issues to be fixed

[will-moore]

@jburel The reason for putting the time since creation is to give you some idea how out-of-date the export is. E.g. if it's only just been done then you don't need to repeat. If it's ancient, you might want to redo it so you get the latest annotations etc. Agree that "Create" is probably nicer than "Prepare".

Discussed the Remove vv Delete issue with Petr the other day - We think that File annotations should behave in the same way as Comments. Single button to Remove - and the file is deleted if it becomes an orphan.

[jburel]

@will-moore, @pwalczysko: We have to be careful with the Remove vs Delete. For an OME-TIFF or jpeg, sure but for a protocol file for example added by mistake to an image that is a problem
So it really depends on the type of file.

For the time, it is maybe better to use something more generic like: today, a week ago than 1min 22sec

[will-moore]

Our thoughts were that the use case of having a Protocol attached to a single Image and then being removed from this Image is VERY rare (probably never happened). So we are continuing to confuse many users of the system by the Delete vv Remove option in order to support a practically non-existent use case.

It's the same for Delete Dataset: "Also delete the images? And delete orphaned files?". We have to make some assumptions instead of asking users to make every decision.

[jburel]

@will-moore, @pwalczysko: Changing UI behaviour should not happen in the point release. We certainly need to review it but not as part of 4.4.x

[will-moore]

@jburel Every PR going into dev_4_4 has UI changes, including this one.

It was your suggestion: "Since you do not have a wait to retrieve FileAnnotation, For OME-TIFF I will only have the delete option not the remove one".

[jburel]

@will-moore, @pwalczysko : As I mentioned before, we need to differentiate between the annotation type i.e. the annotation that can be shared and the other ones. OME-TIFF will not be shared so we can safely delete it.

[will-moore]

As discussed with @jburel we will not change the Delete / Remove options for OME-TIFF or other annotations at this stage.

[jburel]

@will-moore; I am still not convinced by the need to have the time with such level of accuracy. Today. A Week ago etc. will be in my opinion better.

[jburel]

@will-moore:

• log as user-1
  • imported an lsm file
  • Export tas ome-tiff.
  • The file is attached
  • Go back to the Download. This time an error occurred i.e. Server Error (500)

[jburel]

@will-moore: It looks good now.