[ome-devel] Super-Resolution standard format

[Seamus Holden]

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; 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
Subject: Re: Super-Resolution standard format

"Keller, Debora" <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