FAQ

The OME server is a Perl-based system for visualising, managing, and analysing microscope images and metadata. The OME Server was actively developed until 2005, but is no longer actively worked on. Questions or comments can directed to the OME mailing lists or the OME Forums.

OMERO server is an enterprise application written in Java that provides integration, visualisation, management, and analysis of biological image data. The OMERO clients allow the scientist to remotely manage, view, annotate and measure multi-dimensional images from anywhere. It is the focus of our current development effort.

The OMERO server runs on most Unix-based platforms, including Linux and Mac OS X, and Windows subject to certain prerequisites. See Getting Started for more details.

The OMERO.editor tool can be used to add Protocols and Experimental metadata to Projects, Datasets and Images in OMERO. A movie demonstrating this functionality in the OMERO Beta 4.1 release is here.

It is also possible to annotate projects, datasets and images with a Description, add Comments and Tags, as shown in various movies on the OMERO feature list page.

Support for High Content Data was first added to the OME-Data model in June 2007.

The 4.1 and later releases include preview features for working with high-content screening (HCS) data, see high-content screening (HCS) data.

The actual version of the clients (OMERO.insight or OMERO.web) do not support heatmaps.

Yes.

Through the usage of a 64-bit Java virtual machine you can use any of the client applications, OMERO API or OMERO.server on a 64-bit platform.

OMERO.server and clients use the GNU General Public License 2 or later.

OMERO.web uses the Affero GNU General Public License.

The core OME Model Schema files (.XSD) use the Creative Commons Attribution 3.0 Unported License.

There are lots of ways to work with the OME Consortium. Most people use the OME Forums or the Mailing Lists to communicate their needs, status or problems. If you want to work with our source code, feel free to check it out. If at all possible, consider coming to the next OME User's Meeting to meet us, tell us what you're doing and diascuss how we can both help each other.

Details of the best citations to use are available here: Citing OME

As OME is a consortium of separate groups, from different institutions, working together on a common product you will find different copyright messages across our code, documentation, products and publications. These messages reflect the origin of that particular part of our material.

Note: the origin is just that, it does not indicate that people from that institution are responsible for that code now. i.e. If a file is created by Glencoe, but worked on extensively by team members from Dundee, it's copyright will not change.

Agreements exist between the different entities in the consortium to release the material together under a unified license.

Using Bio-Formats, we support conversion from any supported format into a few different "open standard" formats including OME-TIFF. As shown on the supported formats table, you can convert from any format on the list into any format with a green checkmark in the "Export" column.

There are many ways to use Bio-Formats to convert between formats, but two easy ways are the Bio-Formats command line tools and the Bio-Formats plugins for ImageJ.

We have no plans to convert into any vendor's "closed-source" proprietary microscopy formats. Philosophically, we believe that writing to proprietary file formats reinforces the proliferation of proprietary files, and further validates vendors' continued creation of incompatible formats. Instead, we are promoting OME-TIFF as the standard, and believe the community would be best served by petitioning vendors to support OME-TIFF as at least an interchange format. Further, from a practical perspective, we have limited resources, and feel they are better served adding additional readers and fixing bugs rather than creating proprietary format writers. Lastly, the Bio-Formats writer API is open. There is nothing to stop a vendor from creating a writer for their particular format. We would even be happy to include it in Bio-Formats, if they are willing to open source their code.

From 4.1.x, OMERO now imports all the formats read by Bio-Formats including microscopy, HCS, tissue scanner and graphics file formats, over 120 in total. See the supported formats table for full details.

There are a limited number of AVI input compression formats supported by Bio-Formats and thus supported by OMERO.importer:

• MSRLE (Microsoft Run Length Encoding)
• MS_VIDEO
• JPEG

More compression formats are supported if you use a MOV container and have QuickTime for Java installed. However, the portability of QTJ is very limited (Mac OS X and Windows only), it has several bugs, and has been deprecated by Apple.

All these source formats are at present stored uncompressed in OMERO.server after import, so if your goal is to reduce drive space usage overall, having a compressed source movie is not going to help.

Bio-Formats's primary purpose is to convert proprietary microscopy data into an open standard called the OME data model, particularly into the OME-TIFF file format. See the Bio-Formats statement of purpose for a thorough explanation and rationale.

To use Bio-Formats with ImageJ, we recommend using the Fiji distribution. Start Fiji, click the File menu, choose Import, then "Bio-Formats," and choose a data file to import.

To use it as a library, you can use loci_tools.jar (it is a bundle containing all the functionality of Bio-Formats plus optional libraries), or you can use bio-formats.jar separately and download only those optional libraries you need. We have created a guide to using Bio-Formats as a library that will hopefully be useful to you. For further details, see the Bio-Formats as a Java library page.

To use Bio-Formats with ImageJ, we recommend using the Fiji distribution. Start Fiji, click the File menu, choose Import, then "Bio-Formats," and choose a data file to import.

For more information, see the Bio-Formats ImageJ page.

See the Bio-Formats MATLAB page for information on using Bio-Formats with MATLAB.

See the Bio-Formats supported formats page for a detailed list of the supported formats.

We can certainly add support for your data.  In order to do so, we ask that you send any documentation that you may have regarding the file format in which the data is stored, along with a representative collection of example datasets.  Please contact the Bio-Formats team for details on how to send data.

Please see this table: http://trac.openmicroscopy.org/ome/wiki/BioFormats-DatasetStructureTable

Examples of how to save a dataset to multiple files are available on the Bio-Formats export wiki page.

An 'OutOfMemory' error message indicates that the amount of pixel data in a single image plane exceeds the amount of memory allocated to the JVM.  A 'NegativeArraySize' error message indicates that the amount of pixel data in a single image plane exceeds 2 GB.

In the former case, increasing the amount of memory that is allocated to the JVM should solve the problem.  In the latter case, you will need to open the image in sections.  If you are using Bio-Formats as a library, this means using the 'openBytes(int, int, int, int, int)' method in loci.formats.IFormatReader; if you are using Bio-Formats within ImageJ, this means selecting the 'Crop on import' option.

Note that JPEG-2000 is a very efficient compression algorithm - thus the size of the file on disk will be substantially smaller than the amount of memory required to store the uncompressed pixel data.  It is not uncommon for a JPEG-2000 or SVS file to occupy less than 200 MB on disk, and yet have over 2 GB of uncompressed pixel data.

The Slidebook file format is quite complex, and unfortunately we do not have a lot of information about it.  As a result, Bio-Formats must scan through the entire file to find the pixel data, which can be quite slow depending upon the size of the file.

As recent versions of Slidebook support exporting to OME-TIFF, we recommend that you use the Slidebook software to export your .sld and .spl files to OME-TIFF.  You can then use Bio-Formats to open the OME-TIFFs directly.

From a practical perspective, we use Java because it is cross-platform and widely used, with a vast array of libraries for handling common programming tasks. C++ or Python would also have been reasonable choices, but we chose Java because it is easier than C++ and faster than Python, with a larger assortment of de facto standard libraries (e.g., Swing) than either.

Java is also one of the easiest languages from which to deploy cross-platform software. In contrast to C++, which has a large number of complex platform issues to consider, and Python, which leans heavily on C and C++ for many of its components (e.g., NumPy and SciPy), Java code is compiled one time into platform-independent byte code, which can be deployed as is to all supported platforms. And despite this enormous flexibility, Java manages to provide time performance nearly equal to C++, often better in the case of I/O operations.

Historically, LOCI's software projects grew around efforts to harness VisAD, a Java component library for interactive and collaborative visualization and analysis of numerical data, within our VisBio application for visualization of multidimensional microscopy data. We also added support for several microscopy formats to VisAD before splitting the code into a standalone library, Bio-Formats. The choice to use Java and VisAD (rather than, e.g., C++ and VTK) was partially motivated by the fact that LOCI's lead software architect Curtis Rueden was already an expert on Java and VisAD technologies. Choosing Java also enabled cross-platform integration with ImageJ, one of the most popular freely available image processing tools in the life sciences field, as well as with the OMERO system for visualization, management, and annotation of microscopy data.

Java's time performance has been comparable to C++ for many years now, especially in the realm of file I/O where Bio-Formats is focused. According to one thorough study performed in 2005, "Java often outperforms C++ in operations such as memory allocation and file I/O while C++ often outperforms Java in arithmetic and trigonometric operations." This statement is corroborated in an earlier study from 2004 that also includes an I/O benchmark: "If we exclude the trigonometry component, Java performed virtually identically to Visual C++, the fastest of Microsoft's languages." Some of the theoretical basis for such results is discussed in another 2004 article, which also finds that "Java performance on numerical code is comparable to that of C++, with hints that Java's relative performance is continuing to improve."

We have seen two refutations ([1], [2]) of these figures, but neither includes an I/O benchmark, and according to their results Java's computational performance is within a factor of two of C++'s. Even from a pessimistic perspective, we believe the trade-off is acceptable when considering the other advantages of Java such as cross-platform deployment, widespread support and ease of development—as the second article above states: "It seems that it's much, much easier to create a well performing program in Java. So, please consider it for a moment before you start recoding your Java program in C++ just to make it faster."

For further reading, check out this June 2010 article on popular Java myths, and Wikipedia's comparison of Java performance to other languages.

The community has expressed substantial interest in a fully native C/C++ solution for Bio-Formats. We are currently funded to develop complete and robust native Bio-Formats integration capabilities, and we aim to make Bio-Formats the single solution for scientific image access. We will do what is necessary to make that happen.

That said, there are many factors to consider when weighing potential solutions: performance, ease of use, integration, and many others. Our current assessment is that it would not be an efficient use of resources to create a full language translation of Bio-Formats to another language such as C or C++. It would be a project requiring thousands of person-hours that would be better spent improving the codebase we already have. Further, the advantages of Java are too numerous to justify switching completely to another language. While it would be possible (with prolonged effort) to provide the core Bio-Formats library in C or C++ with Java bindings on top, doing so would sacrifice Bio-Formats's platform independence and greatly complicate deployment, especially to Java-based systems such as ImageJ and OMERO. We also expect that a C or C++ version of Bio-Formats would offer no significant improvement in time performance.

Instead, there are several effective ways to harness Java code from other environments; see the Bio-Formats article on interfacing from non-Java code for details. We are committed to exploring and developing these methods further to make Bio-Formats work for as many applications as possible, and welcome community feedback and ideas on this issue.

See the article on interfacing from non-Java code.

In short, no.  Most of the specification documents that we have are covered by non-disclosure agreements; distributing the documents would be a violation of those agreements.  The list of specifications that we have for each format is provided merely as an indication of how well the format is supported and how supportive the format's owner has been of Bio-Formats.

If you really need the specification for a particular format, we advise that you contact the format owner directly.

The GetPhysicalMetadata, PrintTimestamps, and PrintLensNA examples illustrate how to retrieve some commonly used metadata values.  All three examples use the loci.formats.meta.MetadataRetrieve class to retrieve metadata, so it's a good idea to read the Javadocs for MetadataRetrieve in order to determine which methods will give you the metadata that you are looking for.

The 'openImage' method is now in loci.formats.gui.BufferedImageReader.  If 'reader' is the IFormatReader object that you are currently using to open images, then all you need to do is add this line of code after declaring 'reader':

BufferedImageReader imageReader = new BufferedImageReader(reader);

You will then need to replace 'reader' with 'imageReader' in subsequent lines of code.

Bio-Formats is an open project, and as such we strongly encourage other developers to contribute file format reader modules. Our time is limited, and we can use all the help we can get. We have created a guide to coding new file format readers that will hopefully be useful to you in your endeavor, and we would be happy to assist you with any questions or problems you encounter—just email us.

If you are a programmer, you can help by writing and contributing a file format reader module for Bio-Formats—see How do I add support for a file format to Bio-Formats?.

If you are a user, but do not control the format, you can help by letting us know you are interested in the format, and sending us some sample data if possible. Several currently supported formats were added specifically because someone emailed us asking about them. We have an FTP server set up for users to upload large data to us—email us for details.

If you do control the format, you can start by releasing technical details to the community. Publishing a file format specification document, sample data files, and example source code to your web site is extremely useful for external developers to successfully deal with your format. Once you do, we invite you to let us know and we will be glad to work on adding support for the format as our time permits.

If you are a company unwilling to release details publicly, we urge you to reconsider—see Why should my organization open our file format to the community?. If you insist upon keeping your format secret, you could implement your own Bio-Formats file format reader module to enable support in third party applications such as ImageJ, OME and VisBio. Or you could send technical details to the Bio-Formats developers, who will attempt to add support for it, as time permits.

You may feel that by concealing the details of your format, you can "lock in" your customers to a particular software package, or protect your organization in case of errors, but hiding your format has drawbacks:

1. You will generate animosity among your users when they cannot easily perform needed operations on their data. As a result, your users may switch to another vendor, or even build their own systems, the next time they upgrade their hardware (or perhaps even immediately).

2. Your format will almost certainly be reverse engineered anyway, unless you poison your format by hiding behind the DMCA or similar law, in which case your format will be unusable and customers will abandon it completely. Since a reverse-engineered implementation is less likely to completely and correctly reflect the quality and depth of your format, it would be more in your interest to assist the community in an open implementation, or at least provide them with a specification document so that they can create one themselves.

Such an attitude does not serve the best interests of the community, nor is it likely to be advantageous to you, ultimately. Supporting OME-TIFF directly will earn good karma points with your users/customers, while providing yet another impenetrable, incompatible format that makes your users feel trapped and powerless will certainly earn some bad karma.

As OME-TIFF becomes more prevalent, users will increasingly demand direct support for it at acquisition time. It makes more sense to provide this support yourself, rather than rely on a third party such as Bio-Formats to convert the data after the fact.

It may be that OME-XML does not encompass every piece of information you wish to record. However, you can work with the community to extend the specification to accommodate your needs. There are advantages to leveraging the community's efforts:

1. Your developers will spend their time more efficiently, and you will produce a more versatile final product. Though interfacing with the community will require some time investment, you will easily regain any time lost by harnessing community code, and your end result will be both more powerful and more maintainable than otherwise.
2. You will save on support, since many types of support requests will be directed at the community rather than at you specifically. Of course, you will still need to fix bugs in your software. But you will have help from external developers with tasks such as fixing bugs in Bio-Formats and extending the OME-XML specification, whereas if you develop your own proprietary solution, all of these support tasks become your organization's sole responsibility.
3. You will be recognized as a progressive, forward-thinking organization dedicated to improving available microscopy tools.

OME-XML captures all image acquisition and experimental metadata along with the binary image data and packages it into an easily readable structure. See the OME-XML FAQ entry for details.

OME-TIFF stores binary image data in standard multi-page TIFF files, while using OME-XML in the header to preserve rich metadata. See the OME-TIFF for details.

For more technical information about OME-XML and OME-TIFF, see the File Formats.

The one word answer is: compatibility. TIFF files are readable in a large number of existing software tools, and when coupled with OME-XML also flexible enough to accommodate the needs of the microscopy imaging community.

That said, OME-TIFF is merely one example of an alternate pixels container for OME-XML metadata; others are certainly possible. If you do not like TIFF for some reason, you can use the OME-XML format directly, or utilize a different container format. However, we urge you to consider using the OME-XML standard for metadata, rather than creating yet another incompatible metadata representation.

We would recommend:

OME-XML file: filename.ome.xml

OME-TIFF file: filename.ome.tif

We provide an online validator.

This will provide a basic indication of the validity of the file structure. It does not guarantee that the data written in the file structure is correct. The validator also only looks at one file at a time so multi-part OME-TIFF files will show as not being complete. At present it cannot analyse across the multi-part files.

It should be noted that Bio-Formats will still be able to read some files that the validator marks as invalid as it concentrates on reading what data it can, not validation.

You can also browse the source code for the validator which includes a script to run it from the command line.

Alternately, you can validate your file on the command line using Bio-Formats.

The validator does the following steps:

1. If OME-TIFF extract the OME-XML from the header.
2. Examines the OME-XML block and determines the correct schema.
3. Validates the OME-XML against that schema reporting any errors, and then checks with the other older/newer schemas too but just "for info".
4. Scans the OME-XML and records all object IDs.
5. Scans the OME-XML and checks all Refs and Settings objects point to an ID that is present in the file.
6. If OME-TIFF examined the TiffData nodes and calculates the number of TIFF frames needed to make the file complete, then check the TIFF structure to see if there are enough frames present in the file. If not the file is still valid but incomplete (normally part of a multi-file OME-TIFF). Groups of files cannot be checked together yet.

This all is just checking the structure of the data. No attempt is made to make sure the data values make sense.

The LSID specification defines the first three portions as case-insensitive, that is "URN:LSID:(Authority)". The remaining portion is case-sensitive. In OME-XML however we assume lower case for the first two portions "urn:lsid:", for "(Authority)", normally a domain name, any case is acceptable but lower case is recommended for consistency. The remaining portion is case-sensitive.

For full information on our use of LSID in OME-XML see: IDs and LSIDs in OME-XML

First, download and install the Bio-Formats command line tools.

A full tutorial can be found here. In brief, you download and unzip the tools to produce a collection of command line scripts for Unix/Mac and batch files for Windows. The two commands we will use are xmlvalid and tiffcomment.

• xmlvalid – a command-line XML validation tool
• tiffcomment – extracts the OME-XML block in an OME-TIFF file from the comment in the TIFF's first IFD entry.

All scripts require loci_tools.jar is downloaded to the same directory as the command line tools.

Then to validate an OME-XML file sample.ome use:

xmlvalid sample.ome

This validates the XML directly.

Then to validate an OME-TIFF file sample.ome.tif use:

tiffcomment sample.ome.tif | xmlvalid

This extracts the OME-XML from the TIFF then passed it to the validator.

Typical successful output is:

[~/Work/bftools]$ ./xmlvalid sample.ome
Parsing schema path
http://www.openmicroscopy.org/Schemas/OME/2010-06/ome.xsd
Validating sample.ome
No validation errors found.
[~/Work/bftools]$

If any errors are found they are reported. When correcting errors it is usually best to work from the top of the file as errors higher up can cause extra errors further down. In this example the output shows 3 errors but there are only 2 mistakes in the file.

[~/Work/bftools]$ ./xmlvalid broken.ome
Parsing schema path
http://www.openmicroscopy.org/Schemas/OME/2010-06/ome.xsd
Validating broken.ome
cvc-complex-type.4: Attribute 'SizeY' must appear on element 'Pixels'.
cvc-enumeration-valid: Value 'Non Zero' is not facet-valid with respect 
   to enumeration '[EvenOdd, NonZero]'. It must be a value from the enumeration.
cvc-attribute.3: The value 'Non Zero' of attribute 'FillRule' on element 
   'ROI:Shape' is not valid with respect to its type, 'null'.
Error validating document: 3 errors found
[~/Work/bftools]$

OMERO

• The Beta4.3.x (June 2011) version is using the 2011-06 OME-XML schema
• The Beta4.2.x (July 2010) version is using the 2010-06 OME-XML schema
• The Beta4.1.x (December 2009) version is using the 2008-09 OME-XML schema
• The Beta4.0.x (March 2009) version is using the 2008-09 OME-XML schema
• The Beta3.x (June 08-November 2008) version is using the 2008-09 OME-XML schema

OME-Perl server
The OME server is using the 2003 OME-XML schema

About one to two time a year for Major releases. It is driven by users' requests for model changes.

The schema has two kind of releases Major and Minor. A major release happens once or twice a year, normally about February and September. These are key advances and add new functionality. Minor releases are bug fix releases and one or two may happen between Major releases.

The releases are now in sync with releases of OMERO and Bio-Formats.

For more information of the versioning of the releases see

Version Information

Your first step is to suggest it on the forums or mailing list by sending us your use case.

This allows others to provide input to ensure the metadata is added in the most appropriate location so it can work in all cases. From there it will progress to a ticket on the Trac and after research to find the most general name for the term it can get rolled into the next schema release.

In the short term it is also possible to use StructuredAnnotations to store the value into the existing schema.

Binary data is represented in XML using Base64 encoding See RFC 1341 Section 5.2. Binary data is a string of numbers in base 2 represented by a series of bits (binary digits). These same numbers can be represented in base 64 using a series of base 64 digits. The convention for representing base 64 digits is to use the upper and lower case letters (52 digits), the numbers (+10 digits), and two punctuation characters '+' and '/' (total = 64).

Since each byte can represent a value from 0 to 255, we would need two base 64 digits to represent it. If we did that, we would need twice the storage to convert binary into plain text. Instead we can convert 3 bytes at a time into 4-digit base 64 numbers. This makes the plain-text representation of binary data "only" 1/3 larger.

The only requirement is that the ImageDescription directory entry must be present in the first IFD, and populated with a valid OME-XML metadata block.

Otherwise, OME-TIFF files do not need any IFD fields beyond what would be required for a regular TIFF. Please see the TIFF specification for a list of IFD fields required for regular TIFFs.

An OME-TIFF file is in essence a standard TIFF file with an OME-XML metadata block stored inside it. See the OME-TIFF specification for details.

The minimum OME-XML metadata block would conform to the OME-XML minimum specification.

We have a small collection of sample files available that are designed to demonstrate the format.

General simple samples are available from:
http://trac.openmicroscopy.org.uk/ome/browser/ome.git/components/specification/Samples

Also: OME-TIFF samples are available

The Bio-Formats library and command line tools can work with BigTIFF files.

OMERO.importer has support for the format as it is using the Bio-Formats library but you should be aware that when working with very large files you may hit other limitations on image size related to the import and rendering support in the OMERO server.

The addition of the 'Big Image' support into OMERO in v4.2 has removed most, but not all, of these restrictions.

OMERO currently supports the uploading and viewing of some FLIM files, specifically ICS, and STD file formats. Currently the OME-XML model does not support N-Dimensional Data as required by FLIM, so viewing FLIM data that has extra-dimensions such as phase, frequency and time will not be viewed correctly in insight, nor stored or retrieved correctly from OMERO.

We are actively working on adding FLIM to the OME Data Model, Bio-Formats, and OMERO. We have a Trac page which contains our progress so far in adding N-Dimensional data to OMERO.

There is also a detailed discussion on the mailing list.

We have announced our 6D and 7D solution which should provide a stop gap solution for some FLIM data until we can move to full N-Dimensional Data support.

While we have looked at HDF and would be interested to talk to anyone who wants to develop a general HDF solution for storing images and metadata, but we do not at present have an OME format.

Bio-Formats does support some proprietary formats that use HDF and we do make some use of HDF internally in our software.

The OME Remote Objects Server (OMERO) is a modern client-server software platform for visualising, managing, and annotating biological image data. OMERO also provides components for image importing, archiving, protocol recording, and user administration. OMERO consists of a Java server, several Java client applications, as well as Python and C++ bindings and a Django-based web application. See the OMERO feature list.

Though there was a transition period in which both Ice and JBoss were supported, Ice was eventually chosen to be the most appropriate technology:

• Better cross-language support
• Faster binary protocol
• Lower memory overhead

In the end, many of the benefits of a JavaEE application server were not directly applicable to our users, and so the simpler and faster solution was chosen.

Detailed installation instructions are provided on this site. See instructions for Linux / Mac OS X or Windows.

Why do I have to install OMERO.server to use these tools? Most other image processing applications simply install on my desktop.

OMERO is a client-server application and because of this, OMERO is fundamentally different than most image processing applications that you might have used. OMERO integrates image data from many different different sources, (a range of light microscopy, screening, medical imaging, and soon electron microscopy data formats) into a single resource.  A variety of client applications that can all view and analyse data from the same resource.  We separate the functions of the server and client applications so that data intensive operations (reading image data from disk, data compression and analysis) are separated from user interaction functionality.  This means that users can easily access and share large, multi-terabyte datasets using standard laptops, or even handheld display devices.

So, to make all this happen, you have to install OMERO.server and the OMERO client applications.  The client applications are simple, and install just like any other application you use on your desktop or laptop.  OMERO.server is a full-blown enterprise data management application, and installing it takes a bit more time.  We have provided extensive documentation on server installation.

Currently, we do not provide a running OMERO.server for you to load your data into.  If you'd like this facility, please contact Glencoe Software, Inc.

Begin by reading the rest of the FAQ and the troubleshooting page.

If that doesn't help, please try our forum: http://www.openmicroscopy.org/community

The developer documentation for the Matlab bindings to OMERO are available at OmeroMatlab

The configuration guide for deploying OMERO.web in a production environment is available at OMERO.web.

• Firefox 2.0+
• Internet Explorer 7+
• Safari 3+
• Chrome 1+

OMERO.clients provide a platform to annotate objects like: images, datasets and projects stored in OMERO.server. More details about annotating data in OMERO are available on the features page. More details about structure of annotations is available here.

Using the Ice language mapping from http://zeroc.com, OMERO provides access to your data within an OmeroBlitz server from your C++, Java or Python code. More details about OMERO Language Bindings are available:

• for C++
• for Java
• for Python

OMERO uses Bio-Formats to read metadata from incoming image files. In general, if Bio-Formats reads the metadata, then OMERO can store it. Please note that supporting ALL metadata in EVERY image file is a huge undertaking, and is a goal, but not a finished task. If you believe we are missing something, please contact us via either the mailing lists or the forums.

Currently, we are releasing OMERO using PostgreSQL. While support for other RDMS applications is possible, we are just too busy doing other work to also support multiple RDMSs. If you require customization to adapt to another RDMS, contact Glencoe Software, Inc.. They have built an adaptor for OMERO and Oracle 11g.

In our current version, all binary image data, original image files, and annotation data within OMERO are stored in the OMERO Repository.  All other metadata, user info, tags, etc. are stored in the OMERO relational database.

Please see the Backup and Restore instructions.

Images in OMERO should be EXACTLY the same size as the image that was imported. Have you imported the thumbnail from the file?

This is a long and thorny question. Currently, using the standard OMERO clients (OMERO.insight and OMERO.web) the answer is "No". However, following significant discussion with the community, we intend to provide a facility that stores the original metadata, as first loaded during import, and then the latest version of the metadata, including the latest version of edits from a user.

There is nothing to stop developers writing their own clients (using the OMERO API) to edit metadata on the server.

As of the Beta-4.1 release, OMERO attempts to import all of the formats supported by Bio-Formats. The only files that are not supported by the OMERO importer is a very small number of formats that cause errors upon import that we have not had time to address. See the full lists on the Bio-Formats site.

See the SSL section of the OMERO server "Security" page.

Server log files are generated under /var/log, and include the two special files "master.out" and "master.err" as well as several types of rolling files: Blitz-0.log(.1, .2, .3, ...), Processor-0.log(.1, .2, .3, ...)

Client logs files are generated in your home directory under "omero/logs These you can find by going to the "Help" menu and clicking on "Show log file location". In the "log" directory, there are rolling files: importer.log(.1, .2, .3, ...) or omeroinsight.log(.1, .2, .3, ...)

Usually sending us the newest files (those without a numbered ending like ".1") will suffice. If you can then zipping the files first is best.

On all Unix-based systems including Linux and Mac OS X, OMERO clients and server can be installed and run as a regular user. In fact, trying to run the server as root is disallowed.

On Windows, the clients also don't need admin rights, but the server does. Specifically, the user running the server needs rights for starting services.

All ports used by default are above 1024 and also don't require administrator rights.

Whichever user runs the server on any platform will need READ/WRITE permissions to the omero.data.dir.

The OMERO server can use as few as one port (usually either 4063 or 4064). Enabling OMERO.web requires further ports for HTTP and HTTPS. See the Firewall configuration page for a description of the ports used and how to configure them.

See OmeroLogging for more information.

OMERO's support for large images is slightly more complicated than it would appear. OMERO's pixel data interfaces are largely (up to and including OMERO Beta 4.1.x) planar. This means that the smallest unit of work is a 2D section of data; in OMERO nomenclature a "plane". This technique supports very large, multidimensional sets of data very well; up to many, many gigabytes in size.

Where this technique slightly falls down is where very large 2D sections are used. In the run up to the release of OMERO 4.2.0 we began addressing some of these issues which are referred to collectively by the team as "BigImages". We added support for such images in the 4.3.x series.

Begin by reading the troubleshooting page. If that doesn't help, please try our forum

It is possible to download data, image or attachments from the OMERO client to your local machine. Please see
OMERO.insight Managing Data for more information about how to do this.

No, it is currently not possible to download an entire dataset/project from OMERO.

Yes, please look at the OMERO.insight Managing Data page.

You can attach analysis results to Projects, Datasets and images on the server, and interact with them via insight.

See: OMERO.insight Managing Data

an example of uploading and attaching a file can be found here

http://trac.openmicroscopy.org.uk/omero/wiki/PythonClientCodeExamples

Or using the Omero.Tables service:

http://trac.openmicroscopy.org.uk/omero/wiki/OmeroTables

A string representing the time zone is configured in settings.py. Available choices are in the postgres timezone table.

'My account' enables you to personalize your user account. To change your avatar click the Browse button and choose one of your favorite pictures from your hard drive. To edit your avatar click 'Crop this picture'. When you are satisfied with the selected rectangular area of an image click the Crop button. For more details please watch the movie.

Once you have deployed OMERO.web and started the server you can use your browser to access the OMERO.webadmin administration interface on http://your_domain/webadmin/. For more details please click here. If you successfully login you should see the user list like on the screenshot

An administrator panel is also available in OMERO.insight.

Details of how to setup LDAP plug-in are available here

This is a known limitation. You cannot access OMERO using the LDAP root account. Please login using the local OMERO root account and define another LDAP account as an OMERO administrator.

If you want to take an existing (non-LDAP) user and 'upgrade' them to using LDAP you can do so using the OMERO command line tool:

bin/omero ldap setdn

while logged in as an administrator. The process is also reversible so that the OMERO password for a user rather than the LDAP password will be used. See the caveat in the setdn help output below:

    usage: bin/omero ldap setdn [-h] username dn

    Set DN for user (admins only)

    Once the DN is set for a user, the password set via OMERO is
    ignored, and any attempt to change it will result in an error. When
    you remove the DN, the previous password will be in effect, but if the
    user never had a password, one will need to be set!

    Positional Arguments:
      username            User's OMERO login name
      dn                  User's LDAP distinguished name. If empty, LDAP will be disabled for the user

    Optional Arguments:
      In addition to any higher level options

      -h, --help          show this help message and exit

OMERO users standard RFC 2254 LDAP filters (http://www.faqs.org/rfcs/rfc2254.html), so they must conform to that syntax and are only able to do what those filters can do. You can test the filters via ldapsearch on your OMERO server (assuming you have the OpenLDAP binaries installed).

Specific filters

memberOf

If using OpenLDAP make sure your directory has the memberOf attribute correctly configured. Some versions of ApacheDS are known to not support memberOf at all.

Users feedback

LDAP server versions vary. Below, we link to various users experiences on their systems, which may be of use to you:

• http://www.openmicroscopy.org/community/viewtopic.php?f=5&t=631

Each of the OMERO clients offers a specific form for reporting bugs. In that form, users can supply their contact details and describe their problem. All of the bugs and comments submitted from the client applications are handled by the OMERO.QA system which provides support services for users of OME's tools and resources. The QA can be used to track and comment on feedback you have submitted to the team as it is dealt with and also manages the import testing of image files which fail to import properly. These files can be submitted by the OMERO.importer or OMERO.insight when an import error is generated and can also be submitted directly to the QA website. More details about OMERO.qa are available here

Please see the system requirements page.

Please have a look on the troubleshooting page for more information or visit one of our communities to ask a specific question.

OMERO supports distributed computing via the scripting service:

http://trac.openmicroscopy.org.uk/omero/wiki/OmeroPy/ScriptingServiceGuide

More details about OMERO.grid are here:

http://trac.openmicroscopy.org.uk/omero/wiki/OmeroGrid

OMERO.web ships with OMERO.server and require configuration before starting. More details about how to set up the application you can find here

Begin by reading the troubleshooting page. If that doesn't help, please try our forum.

OMERO.server supports the use of an LDAP server to query information for the purposes of automatic user (an ''Experimenter'' or ''Scientist'' in OMERO parlance) creation. Details of how to setup the LDAP plug-in are available here

Currently it is not possible to set up quotas for OMERO accounts.

Configuration Guide for accessing OMERO.web through Apache is available here.

No. Though with regular database dumps as outlined on the backup and restore page, this can be achieved.

You can see detailed backup advice and information about what should be backed up on the backup and restore page.

You can see detailed upgrade documentation for each OMERO version on the OMERO upgrade page.

You can store your OMERO binary repository on a share as long as you are aware of the consequences of that share disappearing and the permissions that are required on that share. The user that is running the OMERO server must be able to read, write and create directories on this share.

If the share disappears or is inaccessible you will see degraded performance, potential problems with search, object indexing, thumbnails and raw data access. It is recommended that you do so with caution and perhaps keep your thumbnail and full text directories on local and/or highly available disk.

If we need to expand the space for the binary repository can it spread across multiple drives? Can we have multiple repositories? What is the best way to do this?

One of our next major features will include a re-examination of the repository infrastructure to hopefully allow more than one. At the moment, however, you can only access one repository.

If you would like to access additional disk space of a new drive from the same OMERO instance, you can symlink some directories from /OMERO off to the new location. /OMERO/Pixels tends to be the largest directory, and it will contain up to 1000 files and 1000 directories. You can move any number of those on the other disk, replacing them with symlinks.

A number of things may be the problem. Good places to start looking for answers are the security (for firewall problems), LDAP (if you are using LDAP authentication) or troubleshooting pages.

OMERO metadata is stored in a relational database (PostgreSQL) and binary data in the OMERO binary repository.

No.

Metadata is stored in a relational database (PostgreSQL) and binary data in an optimized proprietary format in the OMERO binary repository. Export to OME-TIFF is supported.

If you have uploaded the original image when importing you can download it in OMERO.insight or OMERO.web from the download archived files button in the metadata browser.

The exact answer to this depends on

• what type of usage you are expecting (number of simultaneous users, number of images per day, average size of images, etc.)
• if you have already run into performance issues
• what your network and hardware configurations are

Depending on all these and more factors, there are various methods of scaling OMERO and if you contact the list we will do our best to make sensible suggestions.

If you would like to look into the existing load-balancing infrastructure, take a look at:

http://trac.openmicroscopy.org.uk/omero/wiki/OmeroClustering

There are also classes and interfaces that can be used on a sites to providing session-based balancing and failover, but inevitably these need to be tailored to the specific environment. Technical information on these is available here.

Before going down this road, optimizing your PostgreSQL installation, your filesystem, and your available RAM may be more productive.

During the start up of any of our software (bio-formats in ImageJ, importer, insight, webclient, or server) an upgrade check is performed by sending us the following information:

• Java virtual machine version
• operating system details (architecture, version and name)
• current server or client version
• your (external) IP address and HTTP header information (this is standard with every web request your browser makes) .

This information is used to determine if an upgrade is required. We also use this information to determine usage statistics, primarily to support grant applications for our work.

Additionally, when you use the comment or error-feedback feature in our clients you can also send us an optional email address and comment. These feedback messages may also contain the full pathname of any file you were having trouble with (such as the path to your image file or client application).

In all cases, our goal is to collect this data for the purpose of aiding you with your use of OMERO or for the research and development of our products. Other then this, we collect no personally identifiable information.

Further information about our data collection processes can be found here.

The OMERO team develops clients to manage, view, analyse data stored in an OMERO server. View the feature list for more information. The official clients are:

• OMERO.importer (Java Client)
• OMERO.insight (Java Client) with integrated OMERO.editor
• OMERO.web (Web Client)
• OMERO.editor as a standalone Java application

Yes there is: OMERO.web. However in order to fully evaluate the application OMERO rich clients must be used as certain functionality is not available in OMERO.web. This is predominantly:

• Data import
• Region of interest creation and manipulation
• Measurement

You will need:

• The address of the server e.g. test.openmicroscopy.org.uk
• A user name
• A password

Yes, an OMERO ImageJ plugin is available. Visit our download page Downloads

Yes. OMERO.editor has been integrated to OMERO.insight to offer more functionalities. Nevertheless, OMERO.editor can still be used as a standalone application.

The OMERO Java clients work on Windows, Mac OS X or Linux. You will require Java 1.5 or higher

If the application crashed, a window should pop up. You can submit the error without entering any details by pressing the Submit button.

To help tackling the problem, we recommend that you indicate what you were doing when the application crashed. If desired, you can also add your e-mail address, which will allow the feedback system to keep you notified of the status of your feedback. See the QA site for more information.

No, not yet. The acquisition metadata e.g. Objective, Detector are READ-ONLY.

Shoola was the name of our first Java client, used to connect to an OME-Perl server. That version is no longer maintained, but we've kept the name around after migrating Shoola to OMERO.insight.

Now, why Shoola?

Ok, this goes back a ways. In 2004, the OME team met at Don Shula's Steak House in Baltimore, MD (their meeting rooms were cheap, and yes, we bought our coffee at the neighboring Starbuck's). Our meeting room was plastered with pictures of Don Shula, who successfully coached the Miami Dolphins during the 1970's and 1980's. At this meeting, we decided to begin developing our first Java client application. We code-named the project "Shoola". What else could we do after 3 days surround by Don's glory days? The name stuck.

Images in OMERO should be EXACTLY the same size as the image that was imported.

Have you imported the thumbnail from the file?

Some file formats contain two images: the full size one and a smaller version used as a thumbnail by the original application. It can be impossible for us to tell these apart so we may have either imported both or only the first one we found in the file.

No, not yet.  We are certainly working on this.

You can export images from OMERO as OME-TIFF (all image planes are exported and some metadata is included as OME-XML). Other formats for export include jpeg, png and movies (.avi).

Since 4.1.x, a make-movie utility has been added to OMERO. You will be able to make MPEG or QuickTime movie. See the Feature List for a screencast about how to make your own movie.

Please be aware that will only happen if your site blocks outgoing connections to port 4063 and 4064, otherwise connection should be handled automatically.

Currently we do not provide any functionality to configure a proxy and you will not be able to connect to the OMERO server. Please contact your local IT support staff and ask them to open port 4063 and 4064.

See Security for more information.

OMERO java clients do not use HTTP and are not SOCKS proxy compatible. It will not inherit default IE LAN settings to use the proxy/PAC.

Information on the TCP ports that OMERO rich clients use as well as a security briefing is available here:

http://www.openmicroscopy.org/site/support/omero4/server/security

See the following page: How to Build an Agent.

Since version 4.1 there has been significant improvements in the way OMERO and Bio-Formats supports the various Leica file formats. This includes more reliable imports for edge-case files, better meta-data support, color channel display improvements, and support for the archiving/retrieval of all the original files imported.

The OMERO java clients use TCP/IP.

The OMERO java clients try to connect to our update server, to check if you have the latest software. The address of our update server is qa.openmicroscopy.org.uk and it is looked up using your DNS. The IP addresses is not used directly.

OMERO.editor has the option to load protocols and sample files from the internet. These either come from our site or from the URL specified by the user.

Other than that the only connections are to your OMERO server, the address for these is entered at login.

Information about how to use the command line importer can be found on the following support page: Command Line Import

When a file import fails, it should provide you with an error in the importer's "error" tab. From here you can submit the error for correction. Most errors are usually corrected by the next major release.

To help fix the error, we recommend that you send us your original 'failed' file during this process, as well as indicate what you were doing when the application crashed. If desired, you can also add your e-mail address, which will allow the feedback system to keep you notified of the status of your feedback.

To read our documentation on submitting error reports in the importer, click here.

If your file has successfully imports but appears incorrect when viewed in OMERO.insight, please let us know about the problem by visiting our community forums.

Because we are constantly improving the OMERO system, its important to match up your client and server versions. So, if your administrator is currently running OMERO.server version 4.1.X, you should also be running version 4.1.X of the clients.

Sometimes, we release a 'minor' version of the client or server, which should still be compatible with other version in the same 'major' release. For example, the 4.1.0 server is still compatible with 4.1.3 of the clients.

The command line importer allows you to "bulk import" multiple files by passing in a top level directory containing several files rather then passing in a single file by itself. Please note: directory imports are recursive and will try to import all files found in all sub-directories as well.

For details on this function (and to see the full list of command line importer options), visit the CLI Importer page.

A sample video showing how to attach documents to an images/projects/datasets can be found on the features page; this can include pdfs, word documents, protocols, results, etc.

The main steps are selecting the image/project/dataset you want to attach items to then clicking on the '+' button next to the word Attachment in the Annotation section of the right panel.

Due to a memory leak in Java, this feature has been disabled until we can resolve the leak by moving to a solution utilizing OpenGL

Permissions in OMERO were all made private in version leading up to 4.1 because of various difficulties with the security system.

In order to allow group-sharing, a revamp of the permissions took place for 4.2. The intention is that all object graphs (e.g. Project/Dataset/Image) will belong to a single group, and all objects will have the same read permissions.

Mixing objects with different group-ownerships or different read-permissions will not be allowed. Further, a query will only ever return objects belonging to the currently selected group.

The various permissions levels are as follows:

• Private: All data in this group is only visible to the user who owns it and the group owners. The group owner can view the data for other group members but not make any edits (same as read-only behaviour).

• Collaborative - Read-only: Users in groups with this permission setting can view each others' data, but cannot edit or annotate another user's data. You can view another users' images but not comment, rate or tag their images.

• Collaborative: Users in a collaborative group can view and annotate the data belonging to other users. You can tag another user's images or use their tags to annotate your own images. You can add comments to their images and save your own rendering settings for each image. However, you cannot edit the names of their images, projects, datasets, tags etc.

See also Permissions

It is possible for the group owner or server admin to change the permissions level on a group after it has been created and populated with data, with the following limitations:

• It is not possible to 'reduce' permissions to 'Private'. Once links have been created in the database under 'Collaborative' (or Collaborative - Read-only) permissions, these cannot be severed. However, it is possible to 'promote' a Private group to be Collaborative or Read-only permissions.

See Permissions

As in 4.2.x version,

CAN DO:

• Tagging:

  • You can add your tags to your images or another user's images
  • You can add another user's tags to your images, their images or another user's images
  • You can remove tags that you have added

• Comments:

  • You can add comments to your images or another user's images

• Rendering settings:

  • You can apply and save your own rendering settings to another user's images
  • This will not affect their rendering settings on their images

CANNOT DO:

• You can't edit another user's Project, Dataset or Image names or descriptions

• You can't remove Images from another user's Dataset, or remove Datasets (resp. Plate) from Projects (resp. Screen).

• You can't add Images to another user's Dataset, or add Dataset (resp. Plate) to Project (resp. Screen)

• You can't delete anything that belongs to another user

• Tagging:

  • You can't remove a tag that another user has added, even if it is your tag on your own image
  • You can't edit another user's tag names or descriptions

• Comments:

  • You can't edit any comments on any images. Comments are a historical record (same for all permissions levels).

See Permissions

In the 4.2.x and 4.3.x series, it is NOT possible to move data graph between groups. All data a user imports and the work that is done is assigned to the current group and cannot be moved to another group.

See Permissions

Few bugs have been reported when some revisions of Java 1.6 are installed. Error reported on Windows opening a File chooser using Java 1.6.0_20, upgrading to revision (10/01/11 Java 1.6.0_23) should fix the problem (see http://netbeans.org/bugzilla/show_bug.cgi?id=186615):

   java.lang.Exception: Abnormal termination due to an uncaught exception.
   java.lang.InternalError: Unable to bind C:footest
   at sun.awt.shell.Win32ShellFolder2$4.call(Unknown Source)
   at sun.awt.shell.Win32ShellFolder2$4.call(Unknown Source)
   at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Unknown Source)
   

   java.lang.Exception: Abnormal termination due to an uncaught exception.
   java.lang.NullPointerException
   at java.awt.Component.getNormalShape(Unknown Source)
   at java.awt.Component.calculateCurrentShape(Unknown Source)
   at java.awt.Component.applyCurrentShape(Unknown Source)
   at java.awt.Component.mixOnReshaping(Unknown Source)
   at java.awt.Component.reshape(Unknown Source)
   at javax.swing.JComponent.reshape(Unknown Source)
   at java.awt.Component.setBounds(Unknown Source)
   at org.openmicroscopy.shoola.agents.dataBrowser.browser.CellDisplay.setBounds(CellDisplay.java:235)
   

   java.lang.ArrayIndexOutOfBoundsException: 15
   at sun.font.FontDesignMetrics.charsWidth(Unknown Source)
   at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
   at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
   at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
   at javax.swing.text.PlainView.viewToModel(Unknown Source)
   at javax.swing.plaf.basic.BasicTextUI$RootView.viewToModel(Unknown Source)
   at javax.swing.plaf.basic.BasicTextUI.viewToModel(Unknown Source)
   at javax.swing.text.DefaultCaret.positionCaret(Unknown Source)
   at javax.swing.text.DefaultCaret.adjustCaret(Unknown Source)
   at javax.swing.text.DefaultCaret.adjustCaretAndFocus(Unknown Source)
   at javax.swing.text.DefaultCaret.mousePressed(Unknown Source)
   at java.awt.AWTEventMulticaster.mousePressed(Unknown Source)
   at java.awt.AWTEventMulticaster.mousePressed(Unknown Source)
   at java.awt.Component.processMouseEvent(Unknown Source)
   

The following error has been reported while zooming in and out an image. The problem is due to a memory problem in Java. If you see the problem, you may want to try the OpenGL version of the Beta4.1.1 client.

java.lang.OutOfMemoryError: Java heap space
at java.awt.image.DataBufferInt.<init>(Unknown Source)
at java.awt.image.Raster.createPackedRaster(Unknown Source)
at java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)
at java.awt.image.BufferedImage.<init>(Unknown Source)
at org.openmicroscopy.shoola.util.image.geom.Factory.magnifyImage(Factory.java:249)
at org.openmicroscopy.shoola.agents.imviewer.browser.BrowserModel.createDisplayedImage(BrowserModel.java:529)

Things to check:

• Your network connection, are any other applications having a problem?
• Are you running out of memory? Processing large datasets can cause problems
• Is your server's HOME directory on a network share?

When performing some operations the clients make use of temporary file storage and log directories. By default these files are stored below the users HOME directory in $HOME/omero/tmp, $HOME/omero/log and $HOME/omero/sessions. If your home(~) directory $HOME is stored on a network, possibly NFS mounted (or similar), then these temporary files are being written and read over the network. This can slow access down.

The OMERO.server also accesses the $HOME/omero/tmp and $HOME/omero/log folders of the user the server process is running as. As the server makes heavier use of these folders than the clients, if the OMERO.server user's home(~) is stored on a network drive then slow performance can occur.

To resolve this issue for the OMERO.server you can define an OMERO_TEMPDIR environment variable pointing to a temporary directory located on the local file system (e.g. /tmp/).

First, please make sure that you have read through the Troubleshooting page, and that you are using the correct port, username, and password.

If you are still unable to log in using the OMERO clients, then please try clicking the lock symbol on the login window (it should now look like a closed lock).  See also the SSL section of the OMERO security page.

No.

Since 2005, no active OME server development has been undertaken. Almost all development from this point has been towards the continuing evolution and stability of OMERO.server and its clients.

Yes.

While OME server is still "supported" little or no documentation, testing or deployment is being undertaken on new platforms. We will still help you as best we can but suggest that you transition to use of OMERO.

Sample code is provided on the developer sites for each product.

• OMERO: See OmeroClients for general API usage or CodeExamples for a general list of examples.

• BioFormats: See Bio-Formats as a Java library, Export, and Matlab

The source is maintained in git and can be browsed via gitweb.

See the Downloads page for instructions on accessing the source code.

For building everything except for the C++ bindings, OmeroContributing provides details for checking out and building. OmeroCpp has info for compiling the C++ code with Visual Studio.

After checking out the source, you will need to run:

    ./build.py build-eclipse

to have the Eclipse paths properly setup. After that you can either import the top-level OMERO_HOME/.project or any of the individual projects under components. For more information, see the OmeroDevelopement page on the OMERO server trac.

After checking out the source, you will need to run:

    ./build.py build-eclipse

to have the Eclipse paths properly setup. After that you can import either the top-level OMERO_HOME/.project or the individual importer project under components/tools. For more information, see the OmeroDevelopement page on the OMERO server trac.

Most of the projects are built per commit, and builds along with unit tests, and javadocs (or similar) can be found at http//hudson.openmicroscopy.org.uk

Issues for server, clients and the model are all tracked on a single trac site http://trac.openmicroscopy.org.uk/omero

Structured annotations permit the attachment of data and metadata outside the OMERO data model to certain types within the model. More details about structure of annotations is available here.

If you wish to log in by OMERO.insight please follow the instruction on: OMERO.insight.

If you wish to log in by OMERO.web please go to one of the following urls:

• http://your_host/webadmin

• http://your_host/webclient

  

In OMERO, ROIs are defined by one or more Shapes (e.g. Rectangle, Ellipse), allowing an ROI to span multiple Z and T sections.

The position of a Shape on an image plane is given by x and y coordinates from the top left of the image.

Different shapes, listed here are measured differently:

e.g.

• Rectangle has x and y to define the location of the top, left of a rectangle,

whereas

• Ellipse has cx and cy to denote the x, y coordinates of the ellipse center.
  

closeOnDestroy and detachOnDestroy are used to decide whether or not a session will persist after your current client disconnects. If a session is left alive (detached and not closed), then other processes can attach to it and continue processing where the first client left off. If multiple clients connect to a session at the same time, only the setting (closeOnDestroy or detachOnDestroy) of the last session to disconnect will be taken into account. Before that, the session is kept alive.

By default, the setting is "closeOnDestroy". Therefore, if you plan on re-using a session, use detachOnDestroy before calling client.closeSession(). Otherwise, you don't need to worry about either of these methods.

At one point in time, it was suggested that rule based validation of OMERO model objects would be beneficial. While this is still true, the implementation and usage overhead of such a feature was deemed too high at this point. Right now these rules are unimplemented and unused even though some may still appear in OMERO model DSL files.

The OMERO database schema is reasonably large and complex so a diagram is not the greatest way to represent it. As it has been requested a few times we generated one for version 4.1. We would not recommend trying to work from it.

It is available here but is a very large pdf:
Database Diagram for OMERO 4.1 generated March 2010
The PDF has two layers so in an application that supports layers the lines can be turned off to see the tables easier.

If anyone can recommend a good application for generating a diagram from either a Postgres database or direct from the SQL please get in touch.

These stand for:

• access time
• creation time
• modification time

They are to allow clients to write as much information as is available on the linux file system into the database. These values are left in the user space, i.e. the server doesn't try to control them, for example when you access a file the atime is NOT incremented.

These are defined in "file system" terms as opposed to "biologist" frame of reference, where creation could be the "acquisition" timestamp. This acquisition information is stored in the OME data model.

Can you store images back to OMERO from Matlab as doubles? They seem to be rounded to integers.

If you access the pixel values through the API, you can write images back to OMERO as doubles. The values will be stored correctly and if retrieved using the API the values will be correct.

The OMERO rendering engine does not yet support this data type. We have a ticket for that: see #1303. Therefore the OMERO clients cannot display this data correctly at present.

The values are stored correctly and will be viewable through the clients when the rendering engine has been update to full 32 bit data.