Personal tools
  • We're Hiring!

You are here: Home Community Minutes Conference Calls 2007 2007-02-15 Project-wide 3:30 GMT

2007-02-15 Project-wide 3:30 GMT

Attending: Andrew, Brian, Chris, Curtis, Ilya, Jean-Marie, Melissa, Josh


  • Updates to OMERO and Shoola tracs
    • OMERO is currently on Beta2
    • Beta1.1 is released, will be widely announced
    • Beta2 is current milestone

  • OME-XML Updates in OMERO
    • Additional OME-XML suggestions from LOCI
    • Proposal to form a small "OME-XML committee" — Ilya, Andrew and Curtis? — to facilitate more rapid improvements to OME-XML

  • Bio-Formats Updates
    • Discussion of channel min/max issue — clarify what OMERO needs


Chris: where we are with OMERO
  • currently in post-beta1-bug-fixing mode
  • beta1.1 coming out in a week or so, hopefully less
  • beta2 stuff loosely scheduled for beginning of May
  • watch Trac space and Tiki meeting pages for more information over the next few days

Curtis: no place within OME-XML (or on evolution page) for sampling method (e.g., integration)
Ilya: can take place in either hardware or software; commercial systems usually do it in hardware
Curtis: we do it in software (WiscScan handles it)
Ilya: should not be part of Detector then, but probably associated with a particular channel

Curtis: seems to be a conflict for elements like Detector and Laser between what the hardware is vs how the hardware is set for that experiment (Image-specific — e.g., voltage)
Jean-Marie: DetectorRef takes care of that
Ilya: two kinds of voltage — the Detector attribute is for static voltage
Chris: not going to have time to work out all these details right now
Curtis: I'll discuss with Kevin and send a list of LOCI's new XML fields later

Curtis: what do people think about having an "OME-XML committee" (made up of Andrew, Ilya and me?) as a formal group for pushing changes to OME-XML — still poll the community, and all developers still act as advisors, but committee acts as a "public face"
Jean-Marie: part of Andrew's position is for exactly that purpose — someone completely dedicated to improving the XML specification
Andrew: working on a cross-referenced document to clarify which terms are which, in which circumstances

Andrew: want to get a handle on the idea of various levels of OME-XML "compliance" — it is something Bio-Formats should do?
Ilya: we should create a compliance verifier software tool that lets companies put an "OME seal of approval" listing a given level of compliance
Curtis: the requirements for BF are somewhat different — we cannot guarantee anything other than tier 0, because it might not be present in the third-party format being converted — but what we want is to promise that if anything on a particular core list of metadata is present in the format, then we do convert it
Ilya: this is also a problem for various acquisition systems, since many things — even the most basic like physical pixel dimensions, which should be part of tier 1 — are often not automatically recorded, making even tier 1 compliance impossible
Ilya: maybe we could have a tool that allows user to bring a particular collection of metadata "up to spec" to a given tier; it would scan for missing information required for that tier, and prompt the user for it
Curtis: the OME Notebook would be an ideal tool for this
Brian: instead of numbered tiers, we could have types of compliance such as "hardware compliant" and others
Ilya: we aren't sure yet what anything above tier 0 will be anyway, so we should work things out one step at a time

Curtis and Chris discuss Bio-Formats and OMERO. Key points:
  • Bio-Formats min/max logic currently being reworked to require reading the pixels only once; OMERO currently handles min/max computation on its own, but will investigate using Bio-Formats once these modifications are complete
  • Various places in Bio-Formats do not take full advantage of the "pre-allocated buffer" signature of openBytes (e.g., ChannelSeparator) — needs to be improved
  • ChannelSeparator should cache the most recent RGB (interleaved) plane, so that asking for R, then G, then B, does not cause ImageReader to read the same plane from disk three times
  • In the future we may migrate away from using byte[] for openBytes, and instead create some class object (Plane2D mk II?), to keep various associated metadata (e.g., image width and height) with the byte array, and allow for more intelligent behavior such as usage of ByteBuffers to replace the ChannelSeparator plane caching logic

Ilya: status of server integration discussion?
Chris: we discussed it a bit, but need to talk more; Jason owes you a phone call

Action Items

  • Curtis and Kevin will compile a list of LOCI's needed OME-XML improvements
  • Curtis and Melissa will improve BF's preallocated byte array logic
  • LOCI is targeting another BF release for next week, to include Chris's latest improvements, and other recent bugfixes
  • Jason will get in touch with Ilya about server integration requirements
  • Ilya was to find an application of tiling huge 2D images
    • A pathology example where you can click on a case and be presented with a viewer. Click around the various magnifications, use the overview on top to position the magnified view
Document Actions