[ome-devel] Super-Resolution standard format

[Jason Swedlow (Staff)]

Dear All-

Thanks again for the comments, and for the various threads that are ongoing on this topic.

In our experience, the most important step for driving useful formats is the provision of software implementation(s) that people can use, and that exercise some kind of open storage mechanism.  That's the philosophy of Bio-Formats, and why we put so much effort into it.

We've received on this and other threads a lot of suggestions for column names etc- these are hugely helpful.  Now we need the data- good examples of datasets from the Zeiss, Nikon, and any other systems that people are using.  This would include output examples from rapidSTORM or other open source processing tools.  If any of you have good example files for us to play with, please do upload them to the OME team at http://qa.openmicroscopy.org.uk/qa/upload/.  As some of you know, OME puts a premium on data from the community, as this broadens the scope and expertise we sample.

As always, thanks for your comments, support and contributions.

Cheers,

Jason


On 07/07/2015 09:17, "Seamus Holden" <Seamus.Holden at newcastle.ac.uk<mailto:Seamus.Holden at newcastle.ac.uk>> wrote:

Hi all,

I really agree with the previous points regards the importance of improving metadata curation in STORM/ PALM.

However in the context of the SR file format, the point I want to really stress is - the standard will _only_ be adopted if it is easy/ quick to implement! Most early adopters would be SR community hardware and software developers like ourselves - if it takes too much work, they won't do it.

I would suggest a format with an absolutely minimal number of mandatory metadata/ data items, with the rest being optional (even if strongly encouraged) and extensible. Over time, broad adoption of the standard will make it easier to improve or even require the storage  of metadata.

Here is a very rough example specification which could be easily implemented in an XML/ JSON type format:

-- Example SR standard format--
METADATA
( mandatory ) Number of pixels X
( mandatory ) Number of pixels Y
( mandatory ) Size of pixel X
( mandatory ) Size of pixel Y
( mandatory ) Name of localization software
( optional) Resolution
( optional) Laser power
(optional) etc...
DATA COLUMNS (with associated metadata)
X (mandatory)  (metadata: name ('x') units (eg 'nanometers') (further optional column metadata...))
Y (mandatory)  (metadata: name ('y') units (eg 'nanometers') (further optional column metadata...))
T (mandatory)  (metadata: name ('t') units (eg 'ms' or 'frames') (further optional column metadata...))

All other data columns (eg Z, Nphoton, ...) optional.

Thoughts?

Best wishes,
Seamus
Dr Seamus Holden
University Research Fellow
Centre for Bacterial Cell Biology
Newcastle University, UK

-----Original Message-----
From: Ian Dobbie [mailto:ian.dobbie at bioch.ox.ac.uk]
Sent: 06 July 2015 21:22
To: Keller, Debora
Cc: WHEELER Ann; Jason Swedlow (Staff); French, Paul (PHOT) M W; Pedro Almada; Munro, Ian; Joshua Moore; Douglas Russell; Graeme Ball; Simon Li (Staff); Kay Grunewald; Rainer Kaufmann; Yvonne Jones; Dunsby, Christopher W; alex.knight at npl.co.uk<mailto:alex.knight at npl.co.uk>; Ricardo Henriques; Sebastian Schubert; Ilan Davis; Ashley J Cadby; David Susano Pinto; Kwakwa, Kwasi A; Mick Phillips; Mortari, Filippo; Seamus Holden; Michelle Peckham; niko.olivier at gmail.com<mailto:niko.olivier at gmail.com>
Subject: Re: Super-Resolution standard format

"Keller, Debora" <d.keller at imperial.ac.uk<mailto:d.keller at imperial.ac.uk>> writes:

Hi everyone,

Sorry I didn't make it to MMC or Leeds, hopefully next year.

Laser power is not trivial, you'd have to measure the power at the
sample and calculate kw/cm2 for your system. For instance, our Elyra
has a 100 mW 642 laser, but the output at the sample is ~30mW, and
taking into account the FOV (and a Gaussian beam), this leads to
~0.7kW/cm2 (!!!!). I have attached the document Nicolas made for these calculations - could be useful for others.

Sounds useful. We find the new (ish) thorlabs laser detector very useful (http://www.thorlabs.de/thorproduct.cfm?partnumber=S175C).

Regarding SIM data, I am not sure what metadata would be useful, as
apart from the usual (grid spacing, number of rotations, pixel size,
lasers, etc), as the reconstructions seem to be very dependent on the company.

The really crucial piece of data is what is used as the OTF (effectively the microscope calibration), is it deduced from the sample or measured?
It can also be useful to have information about expected stripe width and angle, which can make parameter fitting easier or even unnecessary (depending on how good your data is and stable the system is).

So far only proprietary softwares can be used to reconstruct the data,
and while SIMCheck provides a really neat way to assess the quality of
reconstruction, you can't really compare the ZEN reconstruction
parameters to the OMX one... or can you?

Anyone out there working on OpenSIM? Coz I would love to compare SIM
reconstruction algorithms.

Yes this is something that I have campaigned on and even done some work on but it is not trivial. We are very interested and have done some work towards an open source SIM reconstruction optimised for understandability rather than speed. The Betzig lab (actually Lin Shao) have released their code as open source https://github.com/linshaova/CUDA_SIMrecon
but unfortunately it is CUDA code and not trivial to understand.


Maybe we should push for 3 file formats, one for SMLM, one for SIM and one for STED? The important parameters are very different.

Ian


The University of Dundee is a registered Scottish Charity, No: SC015096
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20150707/f1cbf05f/attachment-0001.html>