2010.11.25-XML Notes-Mk2
OME-XML (Josh, Jean-Marie, Chris, Andrew)
Requirements for improving OME-TIFF
-
Institute in Estonia
- Putting 1000 images in one OME-XML
- Lots of annotations in comments, long, boolean
-
(Jason forwarding screening email)
- Export a single row / column / well group
- Not duplicating XML for each field, plane, etc.
- Jean-Marie using OME-TIFF to communicate with ImageJ
-
Institute in Estonia
OME-TIFF "lite", "basic"?
- Just for display
Namespaces for annotations, etc.
Export
- Where will we export from? (cF. cluster example)
- Doing it in the client?
- Andrew: Transporting one big TIFF and the client can piece it apart
- Chris: exporter has to be modular
- Jean-Marie: a danger is there are no clear strategies on namespace
-
Chris: Delete-like configuration, then choose the images
- Josh: Instrument and a single plane?
- Jean-Marie & Chris: Wait.
Using Metadata levels?
- Josh: something similar in delete and in upcoming chgrp
- Metadata levels are currently just 4 options: ALL, PIXELS-ONLY, ROI
-
Intentation as opposed to implementation
- Not as flexible as delete
- That flexibility is probably overkill for export
-
Then technically do the export
- TIFF per file
- All ZIP'ed
-
Andrew: Metadata-only files?
- OME-TIFFs as the companion file with minimal spec
- Pseudo-schema on top of 2010-06 in OME-TIFF (only )
- Lots of coding work
Steps
- Delete-style options
- Data-layout options (zip, single plane, etc.)
-
Model: how to split the files. (release before server?)
- Andrew: publish but don't release (PREVIEW)
-
SA best practices
- Have to show it in insight/web!
-
Round-tripping
- LSIDs working
- Have a graph which was written in the original import (utility of that?)
-
Full OmeroReader implementation (all 400 methods)
- a couple of individuals; reverse of the Store
- Timescale: something by mid- to late-January
[ I'll write up the steps as tickets under their own requirement ]