Task #3678 (new)
|Reported by:||ajpatterson||Owned by:|
|Keywords:||schema||Cc:||jamoore, dzmacdonald, jburel, cxallan, wmoore, jason, mlinkert, curtis|
Moved from http://www.ome-xml.org/ticket/112
Will highlighted that the new N-Dimensional model will affect how we can represent ROI, and specifically link them to a particular dimension.
- Different images will have different dimensions
- We may want to have a particular ROI on (x,y) but independent of all others, Softworx for instance draws an ROI on the screen, but measurements change depending of Z,T.
- We could have a situation where we have a different ROI tables, or templates of tables for types of imaging.
Josh, 7th Dec notes from ASCB.
"The decision was to start work (simultaneously with the 4.2 release, but
well integrated into the iterations!) on an experimental API (planning
toward for OME 5). This would include a new combined DataService?
(Curtis suggests "OMEIS" ~ :) ) with base methods:
DataBlob? getSlice(Dimension reorderedDims,
long start, long stop, long);
Simpler methods can be built on top of these, and even the legacy APIs
can be kept.
One open questions is where to store the metadata (planeinfo, etc.) We
might prefer to keep it in an HDF file, for example.
The plan is based on the assumption that we will work toward reading
planes directly from the original files with bioformats, which,
however, requires re-import functionality (i.e. hashing).
The n-dimensional work in the server code will most likely happen with
mercurial as a test bed for whether or not it works for us (and
hopefully, to make merging later)"
Sparse Data Collection
- As I understand it, we are *NOT going to support sparse data* with complex pixel types. However it could be supported with Image Container http://trac.openmicroscopy.org.uk/omero/ticket/2552 (Multiple pixels is another possibility but more work & break more code).
- Sparse Data is actually quite a common requirement (will become more so) E.g.:
- I have a stack of fluorescent planes (channel 0) but only 1 plane for transmitted light (channel 1)
- I acquire a DAPI channel and a FLIM channel (which has bins that are not in the DAPI channel).
- I have a transmitted light plane and a wavelength scan for each time point.
- Subsampling of certain dimensions (e.g. 1ms. bursts of high-resolution over a given period) * This could be handled by having burst_delta_T as a different dimension from T.
- Each pixel is an n-bin histogram. Do all the pixels have the same number of bins? If not, it seems like sparse data?
- FLIM (phase method - E.g. Lambert). Extra dimensions are Frequency and Phase. 7 Dimensions in total.
- FLIM with polarisation. http://dx.doi.org/10.1016/j.copbio.2009.01.004 Curtis: "recording whether each event has a positive or negative spin. I don't know all the details of this yet. We have spoken to Klaus Suhling about his work in this area"
- AFM: multiple parameters over scan lines. Needs flexible modelling of the parameters since they are created so frequently. Again, not sure if this is sparse data?
- FCM: multiple parameters per cell
- HCS: representing entire plate in a single structure
- Tomography. Extra dimension is Angle. Usually tilt in 1 direction only, but 2 is possible. "Tilting is a rotation. And rotation is nothing more than one dimension, I agree. But the unit of this dimension is again a new one. It is not nanometers, it is not seconds. it is angles. And you could tilt around any axis. The axis of rotation has one direction and a center of rotation, all with respect to a reference image (not tilted). AT the very least you should be able to store these informations with the data. And the increment is often not constant. There are schemes where you try to have the increment in the sinus of the angle constant. Jean-Marc 13.1.2010"
- Spectral data: "In EELS you could have a full spectum of energies for each pixel. Likewise in EDX but with a resolution different from the EM data. Johannes 12.1.2010"
- Tiling, or "chunking", of very large dimensions. Related to / same as stitching representation (is there a ticket for this?)
- Hashing (corruption detection) and/or compression of various/arbitrary/specific dimensions
This proposal has been updated in line with the 29th June discussion to produce proposal version 4.
The current proposal included here can be edited at Resources/112-NDim/Proposal?.