<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<div id="mail-editor-reference-message-container">
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Richard Mathar said:<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<i>It's difficult to imagine that any data taken from a real instrument need 64 bits (20 decimal digits), i.e. more than 32 bits.<o:p></o:p></i></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Real instruments can produce complex measurements in both meanings: complex numbers or complicated combinations of optical/IR cameras or multispectral measurements. I wouldn’t myself choose to glue separate
numbers together in a single integer pixel array, but other projects/programmers might. That said, I don’t know if anybody does do that. It would typically be a data cube with distinct per-band planes if they don't use an MEF format.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<i><br>
ADC's in the MHz range can produce 16bit data (10 decimal digits).<o:p></o:p></i></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Lots of CCDs have 18-bit A/Ds. These data are usually stored in 32-bit signed integer pixels. (Reduced data might then be 32-bit floats.) FPACK only cares about the values, not the datatype, so the empty space
in each pixel will be efficiently squeezed out when compressed.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<i><br>
The exception are time stamps, if "stamped" by computers that can resolve milliseconds reliably and set the origin at some arbitrary J2000-alike or MJD references. (But clock synchronization is not easy, so in reality only time differences matter to resolve
GRBs etc...)<o:p></o:p></i></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Use cases for high-resolution absolute time stamps are not too hard to find. Optical or radar astrometric observations in the solar system, occultations, pulsar timing can easily drill down to millisecond precision
against an absolute reference like UTC. Commercial GNSS clocks can provide sub-microsecond timing against hardware timestamps. Usually a floating-point representation like MJD is used, but one supposes some project might rely on large integer counts of nanoseconds.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Rob<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>