Skip to content
An OMERO client for downloading data in bulk from the server.
Java Other
  1. Java 99.3%
  2. Other 0.7%
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
src
.dockerignore
.gitignore
.gitlab-ci.yml
.travis.yml
CHANGELOG.md
Dockerfile
IMPLEMENTATION.md
LICENSE.txt
README.md
download.bat
download.sh
pom.xml

README.md

Summary

An OMERO client for downloading data in bulk from the server. The -h option prints a brief summary of command-line options.

From the source repository mvn builds and packages the downloader.

Caveat

OMERO.downloader has not yet seen much use. One should therefore expect both bugs and breaking changes. However, it is hoped that even in its early state there are use cases for which it offers significant help.

Storing downloads locally

For testing, make a new scratch directory, say /tmp/repo/, to specify to the -b option below. In general one should use a separate download directory for each OMERO server from which one fetches data.

Downloading imported image files

./download.sh -b /tmp/repo -s <server host> -u <user name> -w <password> -f binary Image:<image ID>

downloads an image's binary files into the scratch directory. To include companion files use -f binary,companion.

Repeating a download resumes any interrupted files and skips files that are already present.

Within /tmp/repo/Image/ it may seem inconvenient to have each image's downloaded files sorted into separate Binary and Companion directories. However, these are simply symbolic links that can be followed to find the files together within the Repository directory. When binary and companion files should be used together the realpath utility from GNU coreutils can be helpful, e.g.,

showinf -autoscale `realpath /tmp/repo/Image/123/Binary/myimage`

Targeting multiple images

Instead of using Image as a target, containers such as dataset or screens may be specified to target all their images. However, note that for plates the default server configuration disables file download.

Additionally, specifying -a extends the targeted images to include all that are in the same fileset as any targeted image.

Exporting images

A workaround to not being able to download plates is to instead export their images as TIFF. The -f option supports tiff and ome-tiff.

Big images can be exported. Repeating an export resumes any interrupted image tile downloads and skips images that were already exported.

The metadata included in OME-TIFF export currently includes that of the images, ROIs, and some of the simple kinds of annotation on either of those. This can be limited with the -x option if less metadata is desired.

Fetching metadata only

Image metadata is available as OME-XML without pixel data. As for OME-TIFF export the -x option also limits download of this.

ome-xml-parts downloads metadata for images, ROIs and some simple annotations on them as many standalone XML files. For example, with,

./download.sh -b /tmp/repo -s <server host> -u <user name> -w <password> -f ome-xml-parts Image:123

the ROIs on image 123 can then be found as /tmp/repo/Image/123/Roi/*/Metadata/roi-*.ome.xml. Note that these numbered Roi/* directories are themselves symbolic links into /tmp/repo/Roi/.

ome-xml-whole assembles OME-XML export files from the standalone XML files. ome-xml is shorthand for both the parts and whole. So, to export image 123's metadata into one file, simply omit the -parts from the above then check /tmp/repo/Image/123/Export/image-123.ome.xml.

It is possible to directly target annotations and ROIs for metadata export regardless of images.

Licensing

Available as Open Source: see the license for details.

Copyright (C) 2016-2019 University of Dundee & Open Microscopy Environment. All rights reserved.

See also

You can’t perform that action at this time.