<div dir="ltr"><div>Dear all,</div><div><br></div><div>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 <a href="https://docs.google.com/spreadsheets/d/1YxC_WBFEvgy5jo__0_DaC6B0kzy9ptOhc2Z284PnRhU/edit?usp=sharing" target="_blank">google doc</a>.</div><div><br></div><div>Our goals are to follow the BioFormats route and:</div><div> - Create an importer capable of reading most localization data</div><div> - Establish a standard, flexible format that the importer would write into.</div><div><br></div><div>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:</div><div> - Analysis software (eg. clustering) would no longer need to be custom designed for a specific format</div><div> - Rendering could finally be decoupled from the localization software, as the output of any algorithm should be compatible with any rendering method.</div><div> - Comparison of the output of different algorithms could be efficiently compared analytically and visual biases from different rendering methods would be removed.</div><div><br></div><div>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.</div><div><br></div><div>There are also questions of implementation. The BIG.EPFL people <a href="http://bigwww.epfl.ch/smlm/methods/index.html?p=metrics" target="_blank">have tackled this problem </a>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).</div><div><br></div><div>What do you think?</div><div><br></div><div>All the best,</div><div>Pedro</div><div><br>PhD Student<br>Quantitative Imaging and Nanobiophysics Group<br>MRC Laboratory for Molecular Cell Biology<br>University College London<br>Gower Street<br>London</div><div><div><div dir="ltr"><span style="font-family:arial;font-size:small">WC1E 6BT</span><br style="font-family:arial;font-size:small"><span style="font-family:arial;font-size:small">Telephone: <a href="tel:%2B44%20%280%2920%207679%207806" value="+442076797806" target="_blank">+44 (0)20 7679 7806</a></span><br></div></div></div>
<div dir="ltr"><br></div></div>