[ome-users] Fwd: file export

josh.moore at gmx.de josh.moore at gmx.de
Thu Aug 7 11:15:45 BST 2008


Hi Martin,

 > > From: Martin Spitaler <m.spitaler at imperial.ac.uk>
 > > Date: 6 August 2008 04:54:14 GMT-04:00
 > > Hi Jason,
 > >
 > >  if anything, the communication on OMERO works perfectly well -  
 > > good job, everyone!!
 
That's great to hear. Thanks.

 > >  Re: export, I perfectly understand that you can't do everything at  
 > > once, but the feedback routes work, so looking forward to it. But  
 > > what I wonder: You have been using OMERO routinely already, how did  
 > > you handle the interaction between OMERO and data analysis? Analyse  
 > > the original data and upload again? Or with a manual Blitz-style  
 > > interface?

We try to let the cross-language API work as the glue between the
various software components. At the moment we've focused on getting
the data out and into python and matlab scripts. They can then turn
around and upload anything they've produced: new images, tabular data,
etc.

See:
https://trac.openmicroscopy.org.uk/omero/wiki/OmeroGrid
https://trac.openmicroscopy.org.uk/omero/wiki/OmeroMatlab

or an example like:
https://trac.openmicroscopy.org.uk/omero/browser/trunk/components/tools/OmeroPy/projection_1.py


And you're right. Once OME-TIFFs are available via the API, then the
same will be true for a wider range of analysis tools. The major
problem with exporting rather than having the entire API at a programs
disposal is pre-defining exactly what metadata should be available for
processing. In the case of TIFFs, perhaps it is easy enough to say "I
just want the binary data for Image 1", but once a user starts
thinking in terms of exporting an entire dataset, or even a project,
the complexity grows.

This is not to say that we don't want it as part of the API, just that
it's not there yet since there is more to consider. 

Thanks again for your input,
~Josh.


 > >  Re: channels: for a start, I wouldn't bother to much with  
 > > automatic colour assignment, I would rather ask the user at import  
 > > which colour s/he wants for which channel, and use the last user  
 > > choice as default (remember one LAST SETTING per file type). Maybe  
 > > an additional DEFAULT button which writes 1->Red // 2->Green // 3->  
 > > Blue (do you really use BGR instead of RGB? Even microscopy  
 > > software tends to use channels in an RGB-like way). I'm used to  
 > > this from the LSM export, and I think it's the most simple and  
 > > efficient solution.
 > >   As development advances, you could later then add an additional  
 > > option (button) to guess colours from the metadata, or even fancy  
 > > LUTs.
 > > By the way, on the list of companies that write OME-XML or OME-TIFF  
 > > you can add Compix (Hamamatsu) SimplePCI. For some reason I'm  
 > > trying to identify the metadata don't transfer between SimplePCI  
 > > and Volocity (still need to check Omero), but I don't know yet who  
 > > of them is wrong.
 > >
 > > Looking forward to the next developments,
 > >
 > > Martin
 > >
 > > Jason Swedlow wrote:
 > >> Hi Martin-
 > >>
 > >> All good points.  These are clearly important.  A few things-
 > >>
 > >> you can already save any image you are viewing in OMERO.insight--  
 > >> just click on the diskette icon in the toolbar-- this makes a  
 > >> jpeg, .bmp, or .png file.  Obviously, these are not data files--  
 > >> they are more for presentation.
 > >>
 > >> We have waited on supporting OME-TIFF export for a whole bunch of  
 > >> technical reasons, mostly having to do with ensuring all our data  
 > >> modeling details were up-to-date.  this work is largely done, so  
 > >> we can now consider this.
 > >>
 > >> One problem we have with display of multi-channel images is to  
 > >> decide what color to display them as.  Currently, we just use a  
 > >> default-- channel 1 is blue, channel 2 is green, and so on.    
 > >> Since we have to support many file formats, it gets a bit tricky  
 > >> to satisfy everyone-- making sure your images appear in OMERO  
 > >> exactly as they appeared in your normal software is a real  
 > >> challenge.  . however, when we have channel metadata, we could use  
 > >> the channel value to guide the color of the display.  When we  
 > >> don't have this metadata, what should we do?  Any suggestion for  
 > >> an intelligent guess?
 > >>
 > >> Cheers,
 > >>
 > >> Jason
 > >>
 > >>
 > >> On 5 Aug 2008, at 05:31, josh.moore at gmx.de wrote:
 > >>
 > >>>
 > >>> Forwarding to list.
 > >>>
 > >>>> Hi Josh,
 > >>>>
 > >>>> thanks very much for the quick reply. Well, right now I simply
 > >>>> wanted a quick way of converting confocal images to something
 > >>>> useful for various other software, and because the standardised
 > >>>> file format is one of the main strengths of OME / OMERO, it was
 > >>>> obvious to me to try it. Another major reason is that we are in
 > >>>> the process of building up a test run in Imperial College, in
 > >>>> collaboration between my microscopy facility, CISBIC (systems
 > >>>> biology) and some people in physics. So I have started to use
 > >>>> OMERO for real-life images, and was actually very surprised that
 > >>>> you can import everything, but can't get it back out. Because
 > >>>> OMERO is mainly a database, not an image processing tool, which is
 > >>>> only just started to be implemented.
 > >>>>
 > >>>> I know there are beginning to be interfaces with some bits of
 > >>>> software, like CellProfiler or Imaris, but that will never work
 > >>>> with all software.
 > >>>>
 > >>>> So I propose the following export functions for a selection of
 > >>>> images (from the image browser):
 > >>>>
 > >>>>   * a few basic file formats (OME-TIFF, jpg, gif, png)
 > >>>>   * assignment of channels into RGB channels (similar to Zeiss  
 > >>>> LSM export)
 > >>>>   * ideal (that's what I would have needed recently): export of a
 > >>>>   * few special views like maximum projection or tiled channel
 > >>>>     view
 > >>>>   * possible long-term optimisation: movie export
 > >>>>
 > >>>> Please let me know if anything like this is already planned or in
 > >>>> progress.
 > >>>>
 > >>>> Best regards,
 > >>>>
 > >>>> Martin
 > >>>
 > >>> _______________________________________________
 > >>> ome-users mailing list
 > >>> ome-users at lists.openmicroscopy.org.uk
 > >>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
 > >>
 > >>
 > >>
 > >> **************************
 > >> Wellcome Trust Centre for Gene Regulation & Expression
 > >> College of Life Sciences
 > >> MSI/WTB/JBC Complex
 > >> University of Dundee
 > >> Dow Street
 > >> Dundee  DD1 5EH
 > >> United Kingdom
 > >>
 > >> phone (01382) 385819
 > >> Intl phone:  44 1382 385819
 > >> FAX   (01382) 388072
 > >> email: jason at lifesci.dundee.ac.uk
 > >>
 > >> Lab Page: http://www.dundee.ac.uk/lifesciences/swedlow/
 > >> Open Microscopy Environment: http://openmicroscopy.org
 > >> **************************
 > >>
 > >> The University of Dundee is a Scottish Registered Charity, No.  
 > >> SC015096.
 > >>
 > >>
 > >>
 > 
 > 
 > 
 > **************************
 > Wellcome Trust Centre for Gene Regulation & Expression
 > College of Life Sciences
 > MSI/WTB/JBC Complex
 > University of Dundee
 > Dow Street
 > Dundee  DD1 5EH
 > United Kingdom
 > 
 > phone (01382) 385819
 > Intl phone:  44 1382 385819
 > FAX   (01382) 388072
 > email: jason at lifesci.dundee.ac.uk
 > 
 > Lab Page: http://www.dundee.ac.uk/lifesciences/swedlow/
 > Open Microscopy Environment: http://openmicroscopy.org
 > **************************
 > 
 > The University of Dundee is a Scottish Registered Charity, No. SC015096.
 > 
 > 
 > 
 > _______________________________________________
 > ome-users mailing list
 > ome-users at lists.openmicroscopy.org.uk
 > http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users



More information about the ome-users mailing list