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