<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="-1">Hi all,</font><br>
<br>
<blockquote cite="mid:560D27C1.5020604@sussex.ac.uk" type="cite">I
agree that the conversion field I suggested is not perfect. My
idea was that software could choose to write their data using any
units they wanted, so speeding up data writing by not have to
convert during output. However they should provide a method to
convert them to a standard.
<br>
</blockquote>
I agree with Chris and others, that speeding up writing the file is
not an important consideration (unlike speeding up writing image
files, which is a real problem with the OME-Tiff "standard" as also
discussed in this thread), but speed of reading is important.
Moreover, the simple conversions that are required can be executed
very fast so are of no concern at all. More important is whether or
not the writer has access to all the needed data, where the unit for
"Intensity" is the most contentious:<br>
<br>
<blockquote cite="mid:560D27C1.5020604@sussex.ac.uk" type="cite">
For conversion of the Intensity, I left out that the gain would be
ADUs/photon. </blockquote>
What does that mean? I guess that ADU stands for Analog Digital
Unit, which I guess stands for the pixel intensities as provided by
the camera. Common EM-gain CCD cameras spit out digital numbers
whose relation to numbers of photons absorbed by the sensor depend
on the analog gain of the read-out amplifier, the read-out speed,
and the Electron Multiplication gain. In many (most?) situations,
the experimenter has no idea of these things and does not know what
the final conversion factor (from digital numbers to photons)
actually is. That was an issue with the EPFL-led localization
microscopy challenge in which virtually no team provided intensity
data in terms of photons. So, one can decide that data without that
conversion factor are useless, and should not be stored, or one can
allow two units for this field: photons and counts. My vote is for
the latter.<br>
<br>
<blockquote cite="mid:560D27C1.5020604@sussex.ac.uk" type="cite">This
is implied by the requirement that the conversion field converts
the specified unit to the standard. Thus in my example the
conversion for X is nm/Pixel and Frames is seconds/Frame, since
the standard units are nm and seconds respectively.
<br>
</blockquote>
To make this self-evident and human-readable (which are nice
features!) simply include the actual unit (whether it is the only
allowed one or one out of a choice of a few - as needed in the
Intensity field -).<br>
<br>
<blockquote cite="mid:560D27C1.5020604@sussex.ac.uk" type="cite">
If you allow the data to be recorded using any units with the
requirement that the units be included then you are leaving a
problem for anyone reading the file, i.e. they must be able to
understand the units. The options so far suggested are:
<br>
<br>
1. Use standard units
<br>
2. Use any units you want and include the units in the file
<br>
3. Use a subset of defined units for each field and include the
units in the file
<br>
4. Use any units you want and include a way to convert them to
standard units
<br>
<br>
For simplicity option 1 would be the best. It transfers
responsibility to the writer of the file to record the data
correctly. However it does not allow the format to be used in the
case where a calibration to convert to standard units is not
available.
<br>
</blockquote>
Surely go with option 1, however, give alternatives where they are
needed as in the Intensity field. Have a very short list of allowed
fields so that it will be straight forward for readers to deal with
the data. Do not provide conversion factors, since conversions
should be executed up front.<br>
<br>
In all of this, the most important thing to succeed is to provide a
reference implementation/library that can be used from most of the
widely used programming environments, i.e. Java, C, Matlab, and
Python. I am afraid that job will eclipse much of the discussion
here (also note that most of this is already available for the
Tagged Spot File format:
<a class="moz-txt-link-freetext" href="https://micro-manager.org/wiki/Tagged_Spot_File_%28tsf%29_format">https://micro-manager.org/wiki/Tagged_Spot_File_%28tsf%29_format</a>.<br>
<br>
Best,<br>
<br>
Nico<br>
<br>
<br>
<br>
</body>
</html>