[ome-devel] Super-Resolution standard format

[Pedro Almada]

Dear all,

Some of the members of the UK Super-Resolution community have discussed the
integration of single-molecule localization microscopy data (PALM/STORM)
into OMERO and what became completely clear is the need to have a general
way to import the output of the localization algorithms. We've made a push
towards having a general importer and file-standard by looking at the most
common commercial and free software available. The early results are
available as a public google doc
<https://docs.google.com/spreadsheets/d/1YxC_WBFEvgy5jo__0_DaC6B0kzy9ptOhc2Z284PnRhU/edit?usp=sharing>
.

Our goals are to follow the BioFormats route and:
 - Create an importer capable of reading most localization data
 - Establish a standard, flexible format that the importer would write into.

It's our hope future algorithms would then start using a standard format,
since this would finally decouple localization data from the software used
to create it. A few advantages to the SR field would come from this:
 - Analysis software (eg. clustering) would no longer need to be custom
designed for a specific format
 - Rendering could finally be decoupled from the localization software, as
the output of any algorithm should be compatible with any rendering method.
 - Comparison of the output of different algorithms could be efficiently
compared analytically and visual biases from different rendering methods
would be removed.

We need to publicly discuss how to implement this, and we believe the OMERO
developers community is the correct starting point. For now, it seems the
minimum headers common to all datasets are X position, Y position and the
frame number of the localized particle. Other features are immediately
useful such as signal intensity/photon-count but not all formats include it.

There are also questions of implementation. The BIG.EPFL people have
tackled this problem
<http://bigwww.epfl.ch/smlm/methods/index.html?p=metrics>in a fashion, by
creating an XML generator. It asks the user to name the headers, column
separation, etc and an XML is created which is used by their comparison
software to read any text based file such as .csv or .xls. However, some
software packages actually generate binary files and not text based files,
which means an extra exporting step is necessary. Also, XML has an
associated overhead. I would like to see an importer that can handle the
binary data, but have no clue as to how hard that would be to implement (I
can share example outputs though).

What do you think?

All the best,
Pedro

PhD Student
Quantitative Imaging and Nanobiophysics Group
MRC Laboratory for Molecular Cell Biology
University College London
Gower Street
London
WC1E 6BT
Telephone: +44 (0)20 7679 7806
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20150625/94c91d23/attachment.html>