<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="ltr">
<div>
<div>Dear Alex<br>
<br>
Thanks for adding your file formats. As you might've seen earlier in this thread I made a start on a Python script for importing some SR data into OMERO.tables, which is essentaily HDF5 behind the scenes with some OMERO-specific conventions (in terms of metadata
inside the HDF5). Our current (tentative) plans are to stick with this, but remove the OMERO-specific requirements.<br>
<br>
<a href="https://github.com/manics/omero-superresolution-tables">https://github.com/manics/omero-superresolution-tables</a><br>
<br>
<div>Ian Munro has done some work on getting PALM-siever and ThunderSTORM to work with this format.<br>
</div>
<div><br>
</div>
Where we could really use your help is in getting everyone to agree on what columns should be mandatory, their types (for example, should x/y/z always be in nm), and anything else we might've missed.<br>
<br>
</div>
Best wishes<br>
<br>
</div>
Simon<br>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 15 September 2015 at 16:06, Alex Herbert <span dir="ltr">
<<a href="mailto:a.herbert@sussex.ac.uk" target="_blank">a.herbert@sussex.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear All,<br>
<br>
I am the developer of the super-resolution software we use at the GDSC,<br>
University of Sussex. I'm interested in developing a more universal<br>
format for localisation results. My software currently has its own<br>
format and will load localisations using a few other formats too.<br>
Establishing a common format would greatly improve the analysis of data.<br>
<br>
I have added details of my current file formats to the table created by<br>
Pedro Almada:<br>
<a href="https://docs.google.com/spreadsheets/d/1YxC_WBFEvgy5jo__0_DaC6B0kzy9ptOhc2Z284PnRhU/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/spreadsheets/d/1YxC_WBFEvgy5jo__0_DaC6B0kzy9ptOhc2Z284PnRhU/edit?usp=sharing</a><br>
<br>
In short there is a self-documenting text format (using a header) of<br>
tab-delimited column data, one line per localisation; and a binary<br>
format that attempts to be self-documenting (using a header) but is<br>
probably not easy to read outside of Java, although the source code is<br>
available to help understand it.<br>
<br>
The files store many fields that are specific to the fitting algorithm<br>
used. However the position, estimated signal in photons, and original<br>
image dimensions (including pixel sizes) can be extracted from the file.<br>
These are the principle data that should be useful to other software.<br>
Without the original image dimensions the results are reduced to a set<br>
of localisations floating in a space defined by their bounding box. This<br>
is not ideal for reconstructing an image or performing density analysis.<br>
<br>
Regards,<br>
<br>
Alex<br>
<br>
_______________________________________________<br>
ome-devel mailing list<br>
<a href="mailto:ome-devel@lists.openmicroscopy.org.uk" target="_blank">ome-devel@lists.openmicroscopy.org.uk</a><br>
<a href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel" rel="noreferrer" target="_blank">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel</a><br>
<br>
The University of Dundee is a registered Scottish Charity, No: SC015096<br>
</blockquote>
</div>
<br>
</div>
<br>
<span style="font-size:10pt;">The University of Dundee is a registered Scottish Charity, No: SC015096</span>
</body>
</html>