[ome-devel] Super-Resolution standard format

[Alex Knight]

Hi all,

I have to agree with Seamus; the format has to be flexible and self-documenting, with only the essential fields defined as mandatory. Individual programs can always return an error if data they deem to be essential is missing.

It should be implemented using some widely supported framework such as XML; libraries for XML import/export exist in most environments which should it make the format relatively straightforward to implement. This can lead to bigger file sizes but compared to the raw data this shouldn't be a major problem and they should also compress well.

A format for SIM metadata would also be useful. Seamus and Ian I think have all the key points, except that of course the camera pixel size is also essential.

Best Wishes,

Alex

Alex Knight 
Principal Research Scientist
Biophysics and Diagnostics
National Physical Laboratory Hampton Rd | Teddington | Middlesex | UK | TW11 0LW 
t: 020 8943 6308
m: 0773 8895 810
f: 020 8614 0567
e: alex.knight at npl.co.uk
w: http://www.npl.co.uk/biotechnology 

-----Original Message-----
From: Seamus Holden [mailto:Seamus.Holden at newcastle.ac.uk] 
Sent: 07 July 2015 09:17
To: ome-devel at lists.openmicroscopy.org.uk
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; Ricardo Henriques; Sebastian Schubert; Ilan Davis; Ashley J Cadby; David Susano Pinto; Kwakwa, Kwasi A; Mick Phillips; Mortari, Filippo; Michelle Peckham; niko.olivier at gmail.com; Ian Dobbie; Keller, Debora
Subject: RE: Super-Resolution standard format

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

--
If you have received this message in error, please notify us and remove it from your system.
NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses.
 
NPL Management Ltd is a company registered in England and Wales, number: 2937881
Registered office: National Physical Laboratory | Hampton Road | Teddington, Middlesex | UK | TW11 0LW