Personal tools
  • We're Hiring!

You are here: Home Community Minutes Meetings June 2011 Paris User's Meeting Meeting notes

Meeting notes

June 15th, 9:25

Starting early, Jason (UoD) introduced the OME project, goals, and recent development efforts. One improvement, the added support for Volocity in Bio-Formats, even received some applause.

  • On the topic of the added Big Images support, Martin S. (Imperial) asked about whether volumes were supported. At the moment, there is no special handling for them.
  • C. (Curie) asked if there has been any progress toward attaching / linking processed data to the original image, to which Jason answered that it hasn't been done but can be prioritized by the community.
  • Alex (CRUK) asked about the state of the FS changes. Chris A. (UoD)_ responded that currently the "FS Lite" support is limited to single-file PFFs in which the file is archived to OMERO. There was interest in having a solution in which archiving is not necessary. Jaime (Wiezmann) commented that there is an issue of losing control of the file if it is not archived, which Josh (Glencoe) said is definitely true. The reverse issue was also discussed that allowing OMERO to view all files may override the file-level permissions, therefore a good deal of trust must be built up between the OMERO implementation and IT groups. Spencer (Pasteur) commented that a good way to proceed may be to support a very limited use-case first, perhaps via looking for the commonalities across IT departments. Caterina (OMEGA) added that she can understand that biologists, like herself, are attached to their files, but that we need to lead the way showing users that there is a better way, since data on a laptop, for example, can easily be lost. Or, in another way of putting it: what is the vision of what scientists want to do.
  • Spencer (Pasteur) suggested to broaden the appeal of OME by also supporting genomic/NGS/etc. data types, to which Martin S. (Imperial) said that there is currently nothing available in that arena.

Starting at 11:20, Martin S. (Imperial) presented a report on Imperial's efforts to adopt OMERO, including site-wide policies like the requirement to archive files and/or annotate on import from a set of PI-acceptable values. Their test installation which began in 2008 led to a rollout in 2010, and now they have some 40 active users and are seeing added value, e.g. in the form of scripts added by Mark Woodbrige, who could not attend. Remaining issues include transfer speed, linking processing results, and support for 2000 dimensional mass spec.

  • Martin S. (Imperial) explained how difficult it can be to get users to use OMERO without education and advertising, like their microscopy day or monthly FLIM club.

  • Imperial is also undertaking a Full Economic Cost (FEC) evaluation to determine how much this "free, open source" tool actually costs, so that the costs can be shared by users in a transparent manner.

  • Jaime (Weizmann) ask who is responsible for importing data, to which Martin replied that it is each scientist's responsbility, which each PI describing their upload requriements (antibody tags, etc). His facility just provides the infrastructure.

  • Someone from Pasteur asked if it would be possible for Imperial to share the cost estimate. Martin replied that it will be, but it is still unifinished. To the question, is the plan to charge for the database? The answer is more or less yes, but that one is really charging for the storage costs and maintenance. Anything "fancier", like writing scripts, would cost more.

  • Jean-Marie (UoD) asked if the scripts from Mark Woodbrige (Imperial) were to be made available, to which Martin responded, of course and that it would make no sense to repeat the effort. Josh (Glencoe) suggested that Martin could be a first test user of the code section of the forums.

Starting at 11:51, Caterina (OMEGA) presented her vision for using OME to solve a particular problem by re-using existing algorithms. Like the whole OME project, OMEGA tries to be the glue between the algorithms, the data stored in OMERO, and the results, currently stored in OpenBIS, pointing out that the idea is nothing new and was published in 2003 by the OME Consortium.

  • Jason (UoD) asked where the data acquired at Emory was being stored. There was a mis-understanding where the data was uploaded to the demo server at KIT.

  • Alex (CRUK) asked about the advantages of OpenBIS. Caterina responded that the goal is to have storage of the results in a form so that they mean something and are comparable. After evaluating OpenBIS, OMEGA may also evaluate SDCubes or similar projects.

  • Martin S. (Imperial) asked how the trajectory data is stored, and if the values are used on the fly. Currently, it is stored in a self-defined file format of coordinates and labels and is not yet used on the fly.

At 12:20, Jerome (JIC) started his presentation on "OMERO.inAction," a workshop held at JIC to kick-off OMERO use, including his sites use of a wiki for internal communication, even of the output of prcessing steps. After that, he presented his VolViewer 3D volume renderer which has been connected to OMERO.

  • Martin D. (Perkin Elmber) asked whether the wiki functionality could be used to link to SPW/HCS data, which it can. Jerome also mentioned that he wants to look into automatically publishing to a wiki using PyWikipediaBot.

  • Martin S. (Imperial) noted that being able to move the VolViewer server-side is "brilliant".

  • Will Moore (UoD) asked how the authentication works in the wiki. Jerome responded that it's completely browser-based, so one has to first login.

  • Someone asked if there is any automatic 3D alignment. Jerome reponded that there isn't, but that the manual alignment seems to be easy enough.

  • There was also some discussion of how the ROIs were stored. Currently, they are attached as flat files in OMERO, but is looking forward to storing them as OME ROIs.

At 12:37, Johannes Schindelin kindly put some more parts on the table, by presenting a 100-line (python) prototype of an OMERO-FUSE extension. Such a tool would allow accessing data in OMERO from clients which know nothing about the server.

  • Carlos (Glencoe) pointed out that there is an example of doing this already in the OMERO code-base written by him, but is thankful that someone else thinks this is a good idea.

  • Jason (UoD) commented that this should be a way to make a nice, light-weight client.

  • Martin S. (Imperial) noted that this would allow a huge range of possibilities.

After lunch (14:14), Gianluigi (CRS4) presented his (mis)use of OMERO for storing genomic data, pointing out that we are currently at a critical inflection point where our ability to produce genomic data is exceeding very quickly our ability to process it. (Hiring)

Then (14:54), Martin D. (Perkin Elmber) presented Columbus, specifically the selection of populations with the (still unpublished) "Saddle Edge Ridge" (SER) method of generating fingerprints of images or segmented regions.

  • Jaime (Weizmann) asked if the cell textures change if the cells are in motion. Martin D.__ replied that they would, but that the changes should be small enough that the fingerprint similarities could even be used to track the cell.

  • Alex (CRUK) asked about the future of OMERO integration, i.e. if Columbus will be updated to use OMERO 4.3. Martin D. and Jason (UoD/Glencoe) answered that it will, but that there is a lag time, both for Perkin Elmer to integrate the new changes but also for the code to gain stability.

  • Jean-Marie (UoD) asked if there have been any quality comparison between SER and other methods, like those used by CellProfiler. Martin D. answered not yet.

  • Coreen (Curie) asked whether the magnification of the cell plays a role. Martin D. responded that yes, the algorithm is specific to cell size, which shows the success of using OME metadata as an input to processing.

  • Chris A. (UoD) asked whether the algorithm only works on segmented blocks. Martin D. answered that the textures can also be used to classify entire images.

Remotely via skype, BK Cho presented (15:08) OMERO.searcher, which extends the OME Model with context and content information for detecting image similarities. "Cell type" was added as search option, and interesting use of the OMERO.web "basket" feature was made for defining sets of images to base the similarity on.

Stephan Preibisch (Dresden) presented his method of registering SPIM data (15:36), and provided a list of modifications to OMERO and the OME model which would make integration easier (to be sent via email).

  • Chris A. (UoD) asked about the use of compression on the images to which Stephan said that JPEG2000 compression is tough, but some "lossy" compression can be acceptable by chopping off the uninteresting corners of the images. Martin (Imperial) commented that there is also a difficulty in compressing multi-channel images, though each can be compressed separately.

  • Jason (UoD) pointed out that OME has had support for the point spread function from day one and has been waiting on someone to ask for it!

Liz Williams (JCB) described (16:30) the use of original data for the detection of manipulated publication figures, pointing out how the use of OMERO frees the, in this case open source, publisher from the burden of having software to read files from each individual acquisition system.

  • C. (Curie) pointed out how the central repository allows for the re-analysis of the original data, but asked what copyright that would happen under. Liz said that JCB uses a createive commons attribution license.

  • Martin D. (Perkin Elmer) asked what format is used for the "Download original data" feature, which is OME-TIFF.

    • Will Moore (UoD) asked how long upload of original data will be voluntary. Liz said at least until it's a seamless process.

Ingvar (EBI) presented (17:01) the work that he and Will Moore (UoD) did to demonstrate storing the EMDB data in OMERO, which includes using the OpenAstrixViewer embeded in an OMERO.web app.

  • Jean-Marie (UoD) asked if the EMDB community had come to a decision about enforcing/standardizing the metadata model, but they haven't yet, though there is still very much a need to describe and store the iterative workflows which go into creating an EM map.

In closing, Jason (UoD) brought up the topic of a scientific advisory board which everyone in the community should consider. (17:44)

June 16th (Warning: unprocessed)


  • Kevin (9:35)

    • Iteroperability. Not just one program but can work together.
    • writing rich OME-TIFF and linking with it.
    • library ("Forward" effort) has made distributed resources available via METS/MODS
      • capturing experiment information
  • Curtis (9:43)

    • Backwards compatibility but performant with n-dimensions
    • Extensibility, modularity, interoperability
      • Improve architecture & code; extend interoperability; grow the community resources
      • Challenge: to maintain interoperability
        • LegacyLayer rather than a rewrite
    • Modular design, MVC (e.g. to show multiple views of one dataset)
    • IJ1 plugins:
      • Marked in GUI
      • Some edge cases don't work
    • Data model for ImageJ2: imglib
    • Declarative Plugins
      • Previously had to do everything declarative
      • Now, declare inputs / outputs and do the work
      • FW should do the system
    • Example: CellProfiler reads IJ2 plugins
    • Rois is the next goal, using JHotDraw
    • Gathered lots of requirements before starting
    • Adding testing, proj. mgmt tools.
    • Release beta series one per month over the summer. Release afterwards
    • Take home
      • ImageJ2 will work with everything
      • More code we could share.
        • Image-rendering, Big images
    • 9:53
  • Q: link between fiji and imagej2 (Alex CRUK)

    • Fiji is just imagej. Added functionality on imagej1
    • Fiji will be updated to have ImageJ2 as the core
  • Q: Jason - is it the right strategy to take something old and bring it forward

    • Lots of embededded lessons in the IJ1 code
    • Responsibility to the future to document the lessons form IJ1
    • There's a middle ground
    • Look and feel as much as possible as IJ1
  • Q: Alex CURK - vision of rich OME-TIFF and data in OMERO

    • Kevin: same thing. just following the schema
    • Previously didn't have good TIFF writers
    • Following same spec, but filling in more values.
    • Using Bio-Formats to write it, so more robust
    • But that's Java so a limitation
  • Q: C (Curie) multithreading in Java?

    • CurtiS: imglib has functional/per-pixel approach
    • so good for multicore.
  • Q: Will Moore: cellprofiler in UI. Takes any imagej plugin

    • Yes. Could also run imagej for scripting in OMERO
    • Use Lee's bridge? Perhaps.
  • Q: ChriS Allan. A design goal to provide good multi-threading tools?

    • To provide better tools, yes. And easier.

Icy (Fabrice) 10:00

  • Plugins first! Insipred by Excel.

  • Speed! Multi-threaded in plugin, but thread-safe.

  • 5D data structure. DoubleHashMap for stack access and consistency.

  • Overlays (like photoshop) if 5D is not enough.

  • Plugins are versioned, and receive bug reports directly.

  • OMERO wrapper and ImageJ wrapper with compatible input/output (25% faster)

  • Soon to implement ITK and MicroManager

  • Want to integrate OMERO deeply into system (transparent to users)

    • Store more data into system
    • Have some questions about how to do this.
  • 10:19

  • Q: C. (Curie) philosophy about analysis, what to do with measurements? link betwen resulting images

    • For display of results try to display like excel
    • Try to be compatible with output, since it seems that most people are using their own tools
    • Everything made to be exported.
  • Q: Curtis - How do you expect to support MicroManager?

    • Very bundled with ImageJ. On list, they say can you help us, "No"
    • Looked in the code to see why there is the link
    • Didn't want to change the UI, but perhaps because it was an old design, changed the GUI
    • Still using Java level
  • Q: Jason - After a year of development, looking forward, what do we have to do energize this ecology and keep it going?

    • Only thing we need is to use it.
  • Q: Chris Allen - A lot of the work/presentation is single images at a time. Intend to extend plugins without UI? Over many images?

    • Possible to run Icy without a GUI
    • Already have some plugins that work in a pipeline style, including converting data if necessary.
    • In general, though, can also process multiple images at the same time.
  • Q: Alex (CRUK) no one wants to keep writing plugins. Vision for plugin integration

    • 2 projects which are running at the same time
    • Good opportunity to do that at this meeting
    • When writing a new plugin, you won't have the same functionality (dependent libraries)
    • Originally wanted to be compatible with ImageJ
    • imglib will soon have a next version, perhaps it is too soon to integrate.
  • 10:28

Mario, Xuvtools 10:30

  • 3d stitching; no rotations yet.

  • competitor: Stephan P. has a similar tool integrated into Fiji, but no manual iteractions (?)

  • comes from 3d confocal, but now with bio-formats supports more.

  • Q Chris Allen: Size? 8 512x512x16 stacks

  • Thinks in connected components, so it doesn't have to recheck non-related stacks

  • Primarily export as Imaris HDF5 files

  • Calling Bio-Formats from C++ using Jace

    • Pixel copying is too slow
    • Perhaps would fork and talk via sockets
    • Similar to Python-Java wrapper from CellProfiler
  • Have other wrapped libraries: BlitzBioImage (, BlitzImaris, BlitzLSM (discontinued)

  • Looking for programmers

  • Q: Pasteur(?) possible to use OMERO to have something like Google maps

    • Everything is a library which could be used from
    • For the first time, thought about talking directly to OMERO
    • Could just write back stage coordinates for later visualization
  • Q: Curtis - BlitzBioFormats. Did you start with loci bindings?

    • Started there, but needed to change the interface.
    • Curtis: If you made improvements, could we fold those back?
    • Mario: did bug reporting. Definitely. Finally GPL listened.

Julien, Kitware (10:49)

  • Open sourced in 1998 from GE with visualization toolkit (VTK) started in 1993

  • Hiring

  • Copmletely open source (not selling products anymore)

  • Medical, supercomputing, vision, data mgmt.

  • Need of a community

  • Tools that we could share.

  • Distributed visualization

  • Javascript, Java, Flash, and WebGL support in ParaViewWeb

  • ITK started in 2000 from NLM; no visualization

    • Support for MIDAS data management. Want to add OMERO
    • Improving support for large images
  • Let's work together! (research grants, ...)

  • 11:12

  • C: Curtis - Bio-Formats is finished, submitted, but is being reviewed (after suggested changes)

  • Q: Jason - providing "services", we're all building our own integration system, builds

    • We do that. A lot of people are asking about the software process.
    • Currently primarily for C++. Do code reviews
    • Taking a lot of money to take something from PhD to make it useful for everyone. (cF. Documentation, code review, testing)
    • Try to have the tools to do that.


Document Actions