Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Batch download original files 12137 #2220

Closed

Conversation

will-moore
Copy link
Member

This addresses https://trac.openmicroscopy.org.uk/ome/ticket/12137

This PR is on-top of #2219 which should be merged first (or I guess it could be closed if we merge this).

To test, select multiple images in web and try to download from toolbar in right panel.
Try some multi-file images and see how long it takes!
You are given the file count and size of files (before being zipped) in the download option.

if 'image' in objDict:
params = omero.sys.ParametersI()
params.map = {}
params.map["ids"] = rlist([rlong(a.getId()) for a in objDict['image']])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you are using omero.sys.ParametersI(), the map should be automatically initialized and you should be able to use

 params.addIds([a.getId() for a in objDict['image']])

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But how are these then mapped to the key "ids"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jburel jburel added the dev_5_0 label Mar 28, 2014
@will-moore
Copy link
Member Author

The re-working of the file count and size message fixes the issues that @manics raised in #2219. Only remaining question is what to name the zip when downloading multiple images. @imunro Any suggestions?

@imunro
Copy link
Contributor

imunro commented Mar 31, 2014

Would it be easy to prompt the user for a name?

@imunro
Copy link
Contributor

imunro commented Apr 1, 2014

Tested with some of our .sdt files. Behaved as expected (including correct handling of multi-image filesets) . Downloaded files are identical to originals. Looks good. Nice work.

@joshmoore
Copy link
Member

@will-moore:

@will-moore
Copy link
Member Author

@joshmoore This PR is on top of #2219, but both need testing again, just to confirm both single image and multiple images are downloading OK, and there are no bugs when including images that have Pixels instead of Filesets etc.

@manics
Copy link
Member

manics commented Apr 9, 2014

See #2219 (comment)

@manics
Copy link
Member

manics commented Apr 10, 2014

#2219 (comment)

@will-moore
Copy link
Member Author

Main bug reported on #2219 was that OMERO 4 images that had file Archived on import did not allow these files to be 'batch downloaded' when multiple images are selected at once. This is now fixed.

I also added the size of the archived / fileset files when a single image is selected (previously the download menu only showed the count of files.

In addition, I added a couple of new methods to the Blitz Gateway.
This now renders several methods redundant, namely

image.countImportedImageFiles()
image.countFilesetFiles()
image.countArchivedFiles()

However, I won't remove these for 5.0.x since that would be a breaking API change.
But they could be removed from 5.1

@will-moore
Copy link
Member Author

@chris-allan @cneves @knabar BlitzGateway API additions above (and proposed removals when rebasing this to develop).

@joshmoore
Copy link
Member

(NB: this PR will need origin/dev_5_0 merged in)

@jburel
Copy link
Member

jburel commented Apr 15, 2014

@will-moore: do you have a DB that we can test against since we need a mix of 4 and 5 data.

@will-moore
Copy link
Member Author

See the various images on gretzky that are linked from the discussion at #2219

@jburel
Copy link
Member

jburel commented Apr 15, 2014

@will-moore: thanks missed it

…ginal_files_12137

Conflicts:
	components/tools/OmeroPy/src/omero/gateway/__init__.py
@jburel
Copy link
Member

jburel commented Apr 16, 2014

The download options are a bit strange.
If click on an image I have OME-TFF, JPEG, if I have multi-selection, no option only the "0 archived". (for example I click on https://gretzky.openmicroscopy.org.uk/omero/webclient/?show=image-8920%7Cimage-8919%7Cimage-8918)
It will be preferable to have a menu like "original, OME-TIFF, JPEG" certain actions being greyed out depending on the context.

I just noticed that the point was raised by @manics on gh-2219
This should be addressed

@jburel
Copy link
Member

jburel commented Apr 16, 2014

https://gretzky.openmicroscopy.org.uk/omero/webclient/?show=image-9428%7Cimage-9426%7Cimage-9425%7Cimage-9424%7Cimage-9422
5 images selected: 8 archived files. From a usability point of view, counting the log file is misleading. The user won't consider the "log" as an image+ it is not displayed in the browser.

@jburel
Copy link
Member

jburel commented Apr 16, 2014

The download of mixed archived (version 4) and image imported in 5 is working.
Issue with download dialog:

  • pops up on the other side of the screen i.e. click on right-hand side, dialog pops up on the left
  • Download is completed. But the wheel is still spinning

Still some work to be done before the functionality can be merged in and having 2 PR makes it difficult to follow e.g comments

@jburel
Copy link
Member

jburel commented Apr 16, 2014

scoping session to schedule with @gusferguson when he gets back

@will-moore
Copy link
Member Author

This PR was only due to support download of original files. If we want to also support jpeg, OME-TIFF etc, that should be handled in a different PR.

I don't think we should distinguish between log files and other files, since we don't have any logic in the clients to know the difference, and we don't know what users expect for every different format. All we can do is state the facts.

We don't have any way (as far as I know) for the web page to manage the download of files, to know when the download starts or stops. All I can do is show some placeholder prior to requesting the download. Since the download request takes some time (grabbing all the files to a temp folder and zipping them up) I show a spinner gif, but have no control over it after that.

@jburel
Copy link
Member

jburel commented Apr 17, 2014

There is a major change in the UI depending on action. That needs to be addressed, downloading as OME-TIFF does not have to be implemented in that PR but we need to keep some consistency in the UI.
We need to review where we are before going ahead and we now have 3 clients (CLI, web, insight) with "download" functionalities (note that the wording needs to be unified too since we have export/download etc) and they are not always following the same approach/displaying the same info.

@chris-allan
Copy link
Member

Just to add my 2 cents on download and export I definitely agree wholeheartedly with @jburel. Especially with respect to thinking seriously about the implications of this PR in a bit wider scope.

The state of features surrounding download and export functionality has been pretty chaotic of late. In the last few versions we've moved it around in the user interface at least twice and changed the semantics at least once. Our user facing documentation (http://help.openmicroscopy.org/scripts.html) is now even out of date.

We'd certainly have to forgive an end user at this point for being pretty frustrated at the level of flip-flopping and their confusion as to what functionality is where and how to use it. We add to that sense of chaos at our peril.

/cc @gusferguson

@will-moore
Copy link
Member Author

OK - so do I wait for @gusferguson to review this or do I go ahead and add support for JPEG to the multi-image download menu?

@jburel
Copy link
Member

jburel commented Apr 22, 2014

@will-moore: wait for @gusferguson to do a review of what we have already in-place and come up with proposal before going ahead. We can then adjust the various clients.

@jburel
Copy link
Member

jburel commented Apr 24, 2014

@gusferguson is currently reviewing the script menu and the download options and terminology.

@jburel
Copy link
Member

jburel commented May 1, 2014

Closing this PR for now as discussed during yesterday meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants