Requirement #3535 (new)
Opened 13 years ago
Last modified 8 years ago
OME-XML/TIFF export — at Version 7
Reported by: | jamoore | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | Unscheduled |
Component: | General | Keywords: | n.a. |
Cc: | jburel, mtbcarroll, cxallan, mlinkert, jrswedlow, ruben.munoz@…, pearu.peterson@…, jay_copeland@… | Business Value: | n.a. |
Total Story Points: | n.a. | Roif: | n.a. |
Mandatory Story Points: | n.a. |
Description (last modified by cxallan)
It should be possible to export first more metadata with a single image, to have those exports and their included metadata be configurable, to bulk export many images together (including screens or plates) and finally to perform these exports as a background process.
Usage
Possible API usage:
exporter = session.createExporter() exporter.includeAnnotations(); exporter.includeHcs(); exporter.addImage(1L); export.generateTiff();
Notes
OME-XML (Josh, Jean-Marie, Chris, Andrew) * Requirements for improving OME-TIFF * Institute in Estonia * Putting 2000 images in one OME-XML * Lots of annotations in comments, long, boolean * Harvard Screening (Jay Copeland) * Export a single row / column / well group * EMBL Screening (Ruben Muñoz, Jan Ellenberg) * Not duplicating XML for each field, _plane_, etc. * Jean-Marie using OME-TIFF to communicate with ImageJ * 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 <OME uuid=""/>) * 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
Change History (7)
comment:1 Changed 13 years ago by jburel
- Cc mlinkert-x added
comment:2 Changed 13 years ago by jburel
- Description modified (diff)
comment:3 Changed 13 years ago by jrswedlow
- Description modified (diff)
comment:4 Changed 13 years ago by jrswedlow
- Cc jrswedlow ruben.munoz@… pearu.peterson@… jay_copeland@… added
comment:5 Changed 13 years ago by jmoore
- Component set to General
- Milestone changed from OMERO-Beta4.3 to Unscheduled
comment:6 Changed 13 years ago by cxallan
- Summary changed from OME-XML/TIFF import/export to OME-XML/TIFF export
comment:7 Changed 13 years ago by cxallan
- Description modified (diff)
Note: See
TracTickets for help on using
tickets.
You may also have a look at Agilo extensions to the ticket.
Moving to Unscheduled since we are approaching the 4.3 freeze.