2011.02.03-ImageJ Notes

File contents

Agenda: Curtis, Melissa, Adam, Jean-Marie, Josh

== CellProfiler ==

 * Jean-Marie
    * political reasons: good to use OME-TIFF for exchange
 * Adam
    * vague idea of typical OMERO user would like to store their data
    * what would a typical OMERO user would want to store?
    * primarily on analyst, OMERO modules when free
    * would like to specify some metadata/tags for what they're pulling up
    * information on use cases
    * how is data stored.
    * treatments, concentrations
 * Josh & Jean-Marie
    * FLIM example
 * Adam
    * Does & Doesn'ts
    * CellProfiler is segmentation and building a pipeline for many images
    * CPA is more for downstream analysis
    * Only looking at images
    * Plot data from database of measurements
    * Look at interesting phenomena and then see images for validating
    * Most people use it as a classifier, one phenotype then how enriched on a replicate basis
    * Segmentation isn't interested to CPA unless there are measurements made
 * Josh
    * OMERO as middleware
    * maintains ids to link things together
 * Adam
    * currently using mysql database
    * input CSV files or direct DBC
    * read in by CPA
    * we'll have users who already have OMERO and don't want to go through mysql
    * a lot won't both parsing out of file names, etc.
    * add value to analysis and segmentation to have all the information tied together
    * middleware between CP and CPA
    * OMERO users would never have to
 * Josh
    * don't know who this intersection of our communities is
 * Adam
    * true
    * at Broad, people with very specific use cases
    * hard time installing server.
    * using demo server to pull images & metadata
    * people with Data???
        * Josh: Catarina?
    * have an idea of the overlap and it seems significant.
    * keep in mind: trying to do maximum "damage" with minimum time
    * write simple scripts & modules to keep people from doing nasty data massaging
    * Doesn't have to be CP or CPA, support Bio-Formats
    * Not parsing all the metadata.
 * Curtis
    * OME-TIFF is great thing to target as the exchange mechanism
    * reasons to interface directly with OMERO
    * demo: looks like big part of it is classifying large number of images
    * Josh: is this not a deficiency of our data model?
 * Adam
    * Currently, image & object tables
    * would need to abstract away the layer
    * more interested in short-term about how to build a first pass
    * Josh: will need abstraction
        * send us code or data dump
        * extension points
    * Haven't thought about CPA talking to OMERO (rather CP)
    * feature vectors & segmentations. cool.
    * 2D only (split everything)
 * Josh
    * tagging in insight of plate or dataset
    * then run headless
 * Adam
    * as long as there's a column "class" that'd work
    * one option
    * where do we go first from here?
    * talk to Anne some more. where we should start integrating...
    * making it fruitful for imagej
    * trying to make things seamless between the two in the formats that they use
    * would love to see (in an ideal world) OMERO be just the thing
    * but it's nice to also let people export in different formats.
    * Q: Status of port?
        * Adam: tried to get in touch with Donald
        * Should I mock the modules and mirror them?
        * Some of the modules are hard-coded the number of channels.
        * Can now load in arbitrary channels?
        * Josh: hard to know if that is the best way but a good starting point
        * Adam: starting the modules now, and getting a feel for the OmeroPy API
        * What data can we expect to be there? "Will this return something?"
 * Curtis
    * Lists and forums are good.

 * TODOs
    * @@Josh: send email to Catarina & ome-devel

 == ImageJ ==

  * Curtis
    * OME-TIFF is a good idea
    * need more export flexibility
    * seen email thread?
        * Jean-Marie: yes
        * that was work we were planning on
        * was using it in ImageJ
        * and realize that there is a lot missing
        * company that wanted to export in OME-TIFF and view in commercial software
            * they're on 2003-FC
            * perhaps this is a way to get them to upgrade to new versions
            * if user wants to view a newer file
            * poltiical point
    * 2 issues:
        * export for commercial (volocity)
            * ASCB: customers were complaining
            * that will always be a problem
        * just what metadata is exported
            * Andy want more original acquisition metadata (instrument)
            * hardware should come out as an option
            * needed for exposing images in library catalog
            * XSLT from OME-XML to METS, maps well (with a few funnies)
            * problem: some of the information is missing
            * and some of it is only added by users in OMERO
            * example: tags as keywords
            * Josh: reusing the delete code for dealing with pre-defined graphs
        * Josh: also the issue of how to format the bits received
        * Jean-Marie:
            * style-sheet for displaying
            * Curtis: sure, don't need it right away
    * Status of ImageJ
        * OMERO interoperability
            * Still working through the data model
            * imglib, very flexible
            * Container interfaces
            * should be able to add transparent support for OMERO
            * treat image from OMERO like from disk
            * there hasn't been much thought to exchange, but viz. is straight-forward
            * still hammering out data model issues
            * Josh: let's hammer on the ImageJ/OMERO sooner.
        * Josh:
            * We need a way to make good progress
            * Curtis: on the cusp of multi-update sites
            * Don't think thin-driver is that necessary.
            * Part of nature release. Fiji-Berkeley (~1 month)
        * Josh: What are we going to put in the updater?
            * Curtis: just downloading OME-TIFF isn't going to work
            * Need a virtual window.
            * Josh: old interfaces? new interfaces?
            * Curtis: imglib is many interfaces (for ImageJ2)
            * Bioformats plans is still ok.
            * Josh: metadata? Curtis: only small subset supported.
                * Now adding units.
            * Josh: still "plugin on plugin menu"?etc.
                * Curtis: within next year ImageJ2
                    * Don't drop things into plugin/
                    * Use updater. Can be in any plugin.
                    * Would be more nicely packaged.
                * Curtis: within next month ImageJ1
                    * as previously
                * Jean-Marie: no strong opinion
                    * whatever is more realistic
            * Curtis:
                * perceive that helping scientists at Loci
                * (fused with development stand-point)
                * antcipate that people want to work with their data in ImageJ as normal as possible
                * dream: checkin the results of their analysis into OMERO
                * all I want: people to access their data as normal as possible.
                * Jean-Marie: what's sufficient there?
                    * Only way to have all options from plugin was to pass in OME-TIFF.
                    * Pass raw data is quicker
                    * Curtis: plane by plane?
                    * Josh: ...we keep not finding a way to make this work.
                    * Curtis: sit down for 2 days?
                    * Jean-Marie: check calendar for most suitable time.
                    * Curtis: 2 hackathons per year
                    * At user meeting? Sounds good. Stay 2 extra days.
                    * Then we refactored that into ImageJ2