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.

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.

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.

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

Information on using Bio-Formats with ImageJ can be found at http://www.loci.wisc.edu/ome/formats-imagej.html

Information on using Bio-Formats with MATLAB can be found at http://www.loci.wisc.edu/ome/formats-matlab.html

A detailed list of the supported formats can be found at http://www.loci.wisc.edu/ome/formats.html

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.

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

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.

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.

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.

We would recommend:

OME-XML file: filename.ome.xml

OME-TIFF file: filename.ome.tif

We have an online validator located at

http://validator.openmicroscopy.org.uk/

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.

The code for the validator and a script to run it from the command line are located at

http://www.ome-xml.org/browser/Xml/Validator

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:

http://www.ome-xml.org/wiki/LSID

About two to four time a year. 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.

For more information of the versioning of the releases see

http://www.ome-xml.org/wiki/VersionInformation

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 OME-XML 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 StructuredAnnotation to store the value into out 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.

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. Full details of the OME-TIFF specification are at: http://www.ome-xml.org/wiki/OmeTiffSpec

The minimum OME-XML metadata block would conform to the OME-XML minimum specification at:
http://www.ome-xml.org/wiki/MinimumSpecification

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

General simple samples are available from:
http://www.ome-xml.org/browser/Documentation/Samples

OME-TIFF samples are available from:
http://www.ome-xml.org/wiki/OmeTiffData

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.

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. The following page contains our progress so far in adding N-Dimensional data to OMERO:

A detailed discussion can be found here

While we have looked at HDF and would be interested to talk to anyone who wants to develop a HDF solution we do not at present have any support in our software.

OMERO

• 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

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-TB datasets using a 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 on the OME 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..

In our current version, all binary image data, original image files, and data used to annotate 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, in our Beta 4.0.x releases using the standard OMERO clients (Insight and 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, zipping them 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 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 will begin addressing some of these issues. Overarchingly these are referred to by the team as "BigImages".

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.

A description of the methods to download attached files from OMERO via insight is here:

http://trac.openmicroscopy.org.uk/shoola/wiki/OmeroInsightManagingData

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

Yes, please look at page: http://trac.openmicroscopy.org.uk/shoola/wiki/OmeroInsightManagingData

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

see http://trac.openmicroscopy.org.uk/shoola/wiki/OmeroInsightManagingData

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 table.

'My account' allows to personalise user account. For changing avatar click the Browse button and choose one of your favorite pictures from your hard drive. To edit avatar click 'Crop this picture'. When you are satisfy of selected rectangular area of an image click 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

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

Each of the OMERO clients offers a specific form for reporting a bug. In that form user is been given the possibility to give a contact details, like email address and describe more information about the problem occurred. All of the bugs and comments submitted from the client applications are handled by the OMERO.qa. It provides support services for users of OME's tools and resources. It can be used to track and comment on feedback you have submitted to the OME team as it is dealt with. It also manages the import testing of image files which fail to import properly. These files can be submitted by the OMERO.importer 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 LDAP plug-in are available here

Currently, it is not possible to set up the quotas for OMERO account.

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.

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.

The exact answer to this depends on

• what type of usage you're expecting (number of simultaneous users, number of images per day, average size of images, etc.)
• if you've 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'll do our best to make sensible suggestions.

If you'd 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.

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

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.

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.

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).

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

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.

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.

Information about how to use the command line importer can be found on our trac website at: http://trac.openmicroscopy.org.uk/omero/wiki/ImporterCLI

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 on our trac website at: http://trac.openmicroscopy.org.uk/omero/wiki/ImporterCLI.

There is a movie linked off the features page that shows how to attach files to images/projects/datasets, such as pdf or word documents (protocols, results, etc.).

The key step it selecting the images/projects/datasets and clicking on the + button next to the word Attachment in the Annotation section of the right panel.

Due to a memory leak in Java, the feature has to be turned off. We will probably turn that feature back when we fully move to 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 current group.

For more information, see the Permissions 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 subversion and can be browsed via our trac servers:

• http://trac.openmicroscopy.org.uk/omero
• http://trac.openmicroscopy.org.uk/shoola
• http://skyking.microscopy.wisc.edu/trac

See the instructions provided there for how to get involved. For release source code, see the Downloads page.

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 are tracked on the developer trac sites:

• For server related issues, visit http://trac.openmicroscopy.org.uk/omero
• For clients related issues, visit http://trac.openmicroscopy.org.uk/shoola
• For Model related issues, visit http://www.ome-xml.org/

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 have generated one. 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.