Personal tools
  • We're Hiring!

You are here: Home Community Minutes Mini Group meetings OME-XML Meetings 2011.08.16 - ModuloZ Discussion

2011.08.16 - ModuloZ Discussion

Attending: Andrew, Jean-Marie

Draft email/webpage for announcement follows

Interim proposal to support the storage of additional dimensions in the OME model using Z and T

This has been produced as part of our transition to N-dimensional support. It will take a large amount of work throughout the OME specifications and OME software to move to a fully N-dimensional approach to data storage. Given the scale and impact of the change, this will take some time to schedule and complete.

This proposal is designed to allow people wishing to write data with 6 or 7 dimensions into our model today in a way that can be upgraded in the future once N-dimensional support is available.

The key change is the addition of two structured string attributes to the Pixels element. These attributes are ModuloZ and ModuloT. This attributes are optional and if absent the model works as it currently does in the 5D case.

Each of the attributes is a structured string describing the additional dimension embedded in the Z or T data.

The structure of the string is of the form:

"tag:val1 val2 val3 ..."

It starts with a tag describing the type of extra dimension. This can be any string of letters [a-z 0-9 A-Z] with NO punctuation and NO spaces. This must be followed by a single colon ':'. This is designed to allow applications to recognise the kind of the dimension. In our applications we will be including code to recognise and try to display a small number of extra dimensions. To have you dimension recognised by OME code it must use one of the following tags:

"angle:..."
"phase:..."
"histo:..."

Immediately after the colon ':' comes the list of values associated with the individual steps through the extra dimension. This list is space separated.

e.g. a collection of planes taken at the same timepoint but from different angle might use:

ModuloZ="angle:0 45"

The number of space-separated values in the string is used to devise the number of planes in the extra dimension. This is the equivalent of the value stored in TheX, TheY, TheZ, TheT, TheC in the 5D OME Model. If there are 2 values in ModuloZ then the dimension stores two planes for each Z. If there are 25 values in ModuloT then the dimension stores 25 planes for each T.

To find the true value of Z for a plane you need to take the 5D value and divide it appropriately by the number of planes in the extra dimension.

e.g if 3 extra planes are stored for each Z plane

| Number of Z Plane 5D view | True Z Plane | ModuleZ Plane |
|            0              |       0      |       0       |
|            1              |       0      |       1       |
|            2              |       0      |       2       |
|            3              |       1      |       0       |
|            4              |       1      |       1       |
|            5              |       1      |       2       |
|            6              |       2      |       0       |
|            7              |       2      |       1       |
... and so on

How to order the plane data

The order of the plane data defined by the BinData or TiffData block is interleaved as it would be for the 5D view of the Z plane, i.e. it is governed by the value of DimensionOrder on the Pixels element.

Associated issues:

Image<->Image links

In OMERO, the current method that has been put in place for linking two images (e.g., used by the Projection function) adds a wiki-style reference Description of the second image to the ID of the first image . This unfortunately uses IDs that do not survive the export process from the OMERO server to the OME model saved into OME-XML or OME-TIFF files.

Comments

Please add any comments you have here.

Document Actions