Page Contents

OMERO

Downloads
Feature List
Licensing

Previous topic

Example production server set-ups

Next topic

Groups and permissions system

This Page

Note

This documentation is for OMERO 5.2. This version is now in maintenance mode and will only be updated in the event of critical bugs or security concerns. OMERO 5.3 is expected in the first quarter of 2017.

Known limitations

Time zone

We do not recommend changing the time zone on your server. The server is currently set to use local time and changing time zones will result in a mismatch between the original data import times stored in the server and the way the clients report them. A fix for this is forthcoming but will not be in 5.1.

Java issues

OpenJDK8 is supported, however some builds of some releases (such as the current Ubuntu build of 8u40) have broken JPEG support, reported for OpenJDK and Ubuntu. See #12612 and this ome-users thread for more information. OracleJDK8 is also supported, but the earliest releases have had problems. The latest OpenJDK8 or OracleJDK8 should work correctly (we have checked both OpenJDK 1.8.0_45-internal and OracleJDK 1.8.0_66). OpenJDK and OracleJDK version 7 are also supported (we have tested OracleJDK 1.7.0_80 and OpenJDK 1.7.0_85).

Windows OS issues

Failure response on import for new databases

If you have import failures with an error such as:

java.lang.RuntimeException: Failure response on import!
Category: ::omero::grid::ImportRequest
Name: import-request-failure
Parameters: {stacktrace=java.lang.RuntimeException: omero.ValidationException
    serverStackTrace = "ome.conditions.ValidationException: could not
    insert: [ome.model.core.Pixels]; SQL [insert into pixels (creation_id,
    external_id, group_id, owner_id, permissions, update_id,
    dimensionOrder, methodology, physicalSizeXUnit, physicalSizeX,
    physicalSizeYUnit, physicalSizeY, physicalSizeZUnit, physicalSizeZ,
    pixelsType, relatedTo, sha1, significantBits, sizeC, sizeT, sizeX,
    sizeY, sizeZ, timeIncrementUnit, timeIncrement, version, waveIncrement,
    waveStart, image, image_index, id) values (?, ?, ?, ?, ?, ?, ?, ?, ?,
    ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)];
    nested exception is org.hibernate.exception.DataException: could not
    insert: [ome.model.core.Pixels]

when trying to import data to a new database (or possibly one just upgraded to 5.1), it may be an issue with the language encoding during database initialization leading to corrupted Unicode characters, such that any import containing these characters (e.g. µ) will fail with the above exception. A SET CLIENT_ENCODING TO 'UTF8'; command has been added to the database initialization instructions on OMERO.server installation to prevent this.

UTF-8 character limitations in passwords

Windows does not handle non-Latin characters well in the command prompt (console). If you use Unicode characters in your passwords, you may find they are not correctly formed. Therefore, we recommend you avoid them if at all possible.

Binary delete

On Windows servers not all binary files corresponding to a delete may be removed from the binary repository. See Binary data for more details.

Ubuntu issues

Importing using desktop clients

Under older Ubuntu installations, the ‘import folder’ option in the desktop clients currently does not work.

Windows issues

C++ compilation problems

OMERO.cpp will not currently build on Windows due to exceeding DLL symbol limits on this platform, leading to a failure when linking the DLL. It is hoped that this platform limitation can be worked around in a future OMERO release.

Searching

Too many open file descriptors

Starting with OMERO 5, the server works directly from original files. At times, this requires a significant number of open file handles. If you are having problems with large or frequent imports, are seeing “Too many open file descriptors” or similar, you may need to increase the maximum number of open files per process. On Linux, this may be done by setting the nofile limit in /etc/security/limits.conf, for example:

omero  soft  nofile  10000
omero  hard  nofile  12000

This permits the omero user to have 10000 open files per process, which may be increased up to a maximum of 12000 by the user. The username and limits will need adjusting for the specifics of your installation and usage requirements. Note that these settings take effect only for new logins, so the server and the shell or environment the server is started from will require restarting. Run ulimit -a as the user running OMERO to verify that the changes have taken effect.

Deleting datasets

If you have a dataset containing any images which are also present in any other datasets, you will not be able to delete it. First, you must remove the shared images by cutting the links.

Changing group permissions

If a group contains a projection made by one member from data owned by another user, you cannot make the group into a private group.

File format support

Large images with floating-point pixel data

Pyramids of image tiles are currently not generated for images with floating-point pixel data, meaning the imported image will be scrambled if it is over a certain size (configurable using omero.pixeldata.max_plane_height and omero.pixeldata.max_plane_width but set to 3192x3192 pixels by default). This primarily affects the following file formats:

  • Gatan DM3
  • MRC
  • TIFF

Calculation of minima and maxima pixel values

If images are imported with one of the omero import --skip options skipping calculation of the global minima and maxima pixel values, OMERO clients will use the extrema of the pixel type range by default. Users can adjust the minima/maxima via the rendering settings. Recalculating minima and maxima pixel values after import is currently not supported.

Flex data in OMERO.tables

If you are using the advanced configuration setting FlexReaderServerMaps for importing Flex data split between multiple directories for use with OMERO.tables, you should not upgrade beyond 5.0.x. Neither the 5.1 line nor OMERO 5.2 support this functionality.

LDAP

Enabling synchronization of LDAP on user login may override admin actions carried out in the clients, see Synchronizing LDAP on user login for details.