<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=utf-8">
<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;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.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">
<p class="MsoNormal">Hi Gregory and all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As a matter of curiosity, do Rubin operations depend on 64-bit unsigned integers? What are example use cases for 64-bit integers (signed or unsigned) in the community? In the optical and infrared, I would hazard a guess that by far, the
most prevalent raw and pipeline-reduced astronomical pixel data types are unsigned shorts, signed 32-bit integers, and 32-bit floating-point, but a greater diversity of data types must appear in binary tables.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Is there a more recent version of a FITS User’s Guide than <a href="https://archive.stsci.edu/fits/users_guide/">
https://archive.stsci.edu/fits/users_guide/</a> ? Or are there examples of such documentation tailored for particular observatories, projects, purposes, stakeholders?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Rob<o:p></o:p></p>
<div style="mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;padding:0in 0in 1.0pt 0in">
<p class="MsoNormal" style="border:none;padding:0in"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On 3/12/24, 11:52 AM, "Dubois-Felsmann, Gregory P." wrote:</p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">External Email<br>
<br>
I think what we're hearing from the more experienced hands is that that the standard isn't at all concerned with issues like mandating upconversion. In general it's just specifying the mathematical, not the computational, operation, and it is never mandating
a specific in-memory representation in a client.<br>
<br>
But I think there is some guidance at the end of the BZERO section in 4.4.2.5: once the client software has made the (underspecified) determination that BZERO is from Table 11 and BSCALE has "the default value of 1.0", it says "the physical value is computed
by adding the offset specified by the BZERO keyword to the native data type value that is stored in the FITS file". Note that BSCALE is explicitly left out of this; i.e., in this case the standard isn't just relying on the mathematical no-op of multiplying
by one, but is saying explicitly that the client should ignore BSCALE in the calculation.<br>
<br>
We haven't really talked about it, but all the same issues arise with regard to table columns, because of the similar definition of the currently very rarely used TSCALn and TZEROn keywords as having "default" values, rather than distinguishing between the
"provided explicitly" and "not provided" cases.<br>
<br>
Again, as a data publisher, I know the difference between "I am publishing an integer column that I expect users to see as integral" versus "I am publishing a generic numeric column and I'm trying to save space by packing it into a 16-bit integer and scaling
it". It would be nice to have a spec that says somewhat more precisely what I'm supposed to do to convey the former message unambiguously, particularly because if it's a 64-bit integer I very much indeed want to send client software a signal that I don't
want it to be accidentally "promoted" to 64-bit float.<br>
<br>
Obviously as a data provider I'm not going to troll my users by fiddling with my melodramatic 0.999999999999999s. For signed integers I'm going to omit BZERO/TZEROn and BSCALE/TSCALn altogether and I'm confident that Paul's library will do what I want no matter
what we say on this thread.<br>
<br>
But if I'm trying to publish an unsigned integer, I am genuinely uncertain about whether I have to worry about whether a client's behavior will depend on whether I say "9223372036854775808" or "9223372036854775808.", and the consequence of it mattering is potentially
information-destroying. I will err on the side of caution and write the former, of course, but I'd rather have the standard on my side here.<br>
<br>
As a side remark, I hope we can discuss such things without the people who put so much work into what is already in the standard feeling denigrated, and avoiding value judgements about the quality of people's work.<br>
<br>
Gregory<br>
<br>
________________________________________<br>
From: fitsbits <fitsbits-bounces@listmgr.nrao.edu> on behalf of Barrett, Paul via fitsbits <fitsbits@listmgr.nrao.edu><br>
Sent: Tuesday, March 12, 2024 07:57<br>
To: Seaman, Robert Lewis - (rseaman)<br>
Cc: fitsbits@listmgr.nrao.edu<br>
Subject: Re: [fitsbits] Output array type when BZERO is an integer {External}<br>
<br>
I'll ask this question one more time and then I'll let it go.<br>
<br>
I understand that the default behaviour for BZERO and BSCALE creates a floating point array because of the typical upconversion rules. However, I'm not clear about the data type for the special case where BZERO is an integer. In this case, it appears that BZERO
is added first to the integer array before converting it to a floating point array, because BSCALE = 1.0 implies upconversion. Is this correct?<br>
<br>
<br>
As for your comments:<br>
<br>
* I disagree with your first comment. FITS is used because of peer pressure. It is mandated by NASA. That means a large sector of the community HAS to use it.<br>
* Yes, dynamic languages are dynamic enough. In the case of Julia, it can do everything that C/C++, FORTRAN, and Python can do. Think of Julia as Python with Numba built-in.<br>
<br>
-- Paul<br>
<br>
On Tue, Mar 12, 2024 at 9:39 AM Seaman, Robert Lewis - (rseaman) via fitsbits <fitsbits@listmgr.nrao.edu<mailto:fitsbits@listmgr.nrao.edu>> wrote:<br>
Howdy,<br>
<br>
It is always good to see a spirited FITS discussion! A few more peppy points:<br>
<br>
<br>
* There is always an assertion that it would be preferable to use a “modern” format<br>
<br>
* Yet projects often end up using FITS<br>
* This choice does not result from peer pressure<br>
<br>
<br>
* There is nothing magic about IEEE floating point or twos-complement integers<br>
<br>
* Efficient (compressed) data representations may not even be binary (Rice is unary)<br>
* Are dynamically typed languages dynamic enough?<br>
<br>
<br>
* A tile-compressed image is a simple binary table<br>
<br>
* My first encounter with FITS data (c. 1983) was writing a FITS image reader from scratch by consulting the original journal article(s) (possibly also my first encounter with C)<br>
* I am confident young Rob could have written a reader for tile-compressed binary data with little more effort (or code) just from reading the current FITS standard<br>
<br>
<br>
* FITS documentation is pretty good<br>
<br>
* (Comments about other projects’ documentation omitted)<br>
<br>
<br>
* Most FITS discussions/disagreements are about metadata<br>
<br>
* Only a small minority of FITS metadata is strictly required to enforce the structure of each extension<br>
* Science metadata (astronomical and computer science) would be legal (and trivial) to represent, using any schema you like, in a binary table structure, described in a convention or appendix or chapter of the standard<br>
* Schemata could also include language-specific pragma, for data-typing purposes or otherwise<br>
<br>
<br>
* It is perhaps peer pressure that pushes projects to use 80-char ASCII header keywords in 2880-byte records<br>
<br>
* Consider, rather, what is the optimal tiled representation for your project, and separately<br>
* How can your project’s (and community) metadata best be represented in a schema realized as a binary table?<br>
<br>
Rob<br>
<br>
_______________________________________________<br>
fitsbits mailing list<br>
fitsbits@listmgr.nrao.edu<mailto:fitsbits@listmgr.nrao.edu><br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a></p>
</div>
</div>
</div>
</div>
</body>
</html>