<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-family: Calibri, sans-serif; font-size: 14px; color: rgb(0, 0, 0);">
<div>Dear All-</div>
<div><br>
</div>
<div>Thanks again for the comments, and for the various threads that are ongoing on this topic.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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 <a href="http://qa.openmicroscopy.org.uk/qa/upload">http://qa.openmicroscopy.org.uk/qa/upload</a>/.
As some of you know, OME puts a premium on data from the community, as this broadens the scope and expertise we sample. </div>
<div><br>
</div>
<div>As always, thanks for your comments, support and contributions.</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Jason</div>
<div><br>
</div>
<div><br>
</div>
<div>On 07/07/2015 09:17, "Seamus Holden" <<a href="mailto:Seamus.Holden@newcastle.ac.uk">Seamus.Holden@newcastle.ac.uk</a>> wrote:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>Hi all,</div>
<div><br>
</div>
<div>I really agree with the previous points regards the importance of improving metadata curation in STORM/ PALM.
</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>Here is a very rough example specification which could be easily implemented in an XML/ JSON type format:
</div>
<div><br>
</div>
<div>-- Example SR standard format--</div>
<div>METADATA</div>
<div>( mandatory ) Number of pixels X</div>
<div>( mandatory ) Number of pixels Y</div>
<div>( mandatory ) Size of pixel X</div>
<div>( mandatory ) Size of pixel Y</div>
<div>( mandatory ) Name of localization software</div>
<div>( optional) Resolution</div>
<div>( optional) Laser power</div>
<div>(optional) etc...</div>
<div>DATA COLUMNS (with associated metadata)</div>
<div>X (mandatory) (metadata: name ('x') units (eg 'nanometers') (further optional column metadata...))</div>
<div>Y (mandatory) (metadata: name ('y') units (eg 'nanometers') (further optional column metadata...))</div>
<div>T (mandatory) (metadata: name ('t') units (eg 'ms' or 'frames') (further optional column metadata...))</div>
<div><br>
</div>
<div>All other data columns (eg Z, Nphoton, ...) optional.</div>
<div><br>
</div>
<div>Thoughts?</div>
<div><br>
</div>
<div>Best wishes,</div>
<div>Seamus</div>
<div>Dr Seamus Holden</div>
<div>University Research Fellow</div>
<div>Centre for Bacterial Cell Biology</div>
<div>Newcastle University, UK</div>
<div><br>
</div>
<div>-----Original Message-----</div>
<div>From: Ian Dobbie [<a href="mailto:ian.dobbie@bioch.ox.ac.uk">mailto:ian.dobbie@bioch.ox.ac.uk</a>]
</div>
<div>Sent: 06 July 2015 21:22</div>
<div>To: Keller, Debora</div>
<div>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;
<a href="mailto:alex.knight@npl.co.uk">alex.knight@npl.co.uk</a>; Ricardo Henriques; Sebastian Schubert; Ilan Davis; Ashley J Cadby; David Susano Pinto; Kwakwa, Kwasi A; Mick Phillips; Mortari, Filippo; Seamus Holden; Michelle Peckham;
<a href="mailto:niko.olivier@gmail.com">niko.olivier@gmail.com</a></div>
<div>Subject: Re: Super-Resolution standard format</div>
<div><br>
</div>
<div>"Keller, Debora" <<a href="mailto:d.keller@imperial.ac.uk">d.keller@imperial.ac.uk</a>> writes:</div>
<div><br>
</div>
<div>Hi everyone,</div>
<div><br>
</div>
<div>Sorry I didn't make it to MMC or Leeds, hopefully next year. </div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>Laser power is not trivial, you’d have to measure the power at the </div>
<div>sample and calculate kw/cm2 for your system. For instance, our Elyra </div>
<div>has a 100 mW 642 laser, but the output at the sample is ~30mW, and </div>
<div>taking into account the FOV (and a Gaussian beam), this leads to </div>
<div>~0.7kW/cm2 (!!!!). I have attached the document Nicolas made for these calculations – could be useful for others.</div>
</blockquote>
<div><br>
</div>
<div>Sounds useful. We find the new (ish) thorlabs laser detector very useful (<a href="http://www.thorlabs.de/thorproduct.cfm?partnumber=S175C">http://www.thorlabs.de/thorproduct.cfm?partnumber=S175C</a>).
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>Regarding SIM data, I am not sure what metadata would be useful, as </div>
<div>apart from the usual (grid spacing, number of rotations, pixel size, </div>
<div>lasers, etc), as the reconstructions seem to be very dependent on the company.</div>
</blockquote>
<div><br>
</div>
<div>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?</div>
<div>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).</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>So far only proprietary softwares can be used to reconstruct the data, </div>
<div>and while SIMCheck provides a really neat way to assess the quality of </div>
<div>reconstruction, you can’t really compare the ZEN reconstruction </div>
<div>parameters to the OMX one… or can you?</div>
<div><br>
</div>
<div>Anyone out there working on OpenSIM? Coz I would love to compare SIM </div>
<div>reconstruction algorithms.</div>
</blockquote>
<div><br>
</div>
<div>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 <a href="https://github.com/linshaova/CUDA_SIMrecon">
https://github.com/linshaova/CUDA_SIMrecon</a></div>
<div>but unfortunately it is CUDA code and not trivial to understand.</div>
<div><br>
</div>
<div><br>
</div>
<div>Maybe we should push for 3 file formats, one for SMLM, one for SIM and one for STED? The important parameters are very different.
</div>
<div><br>
</div>
<div>Ian</div>
<div><br>
</div>
</blockquote>
<br>
<span style="font-size:10pt;">The University of Dundee is a registered Scottish Charity, No: SC015096</span>
</body>
</html>