[fitsbits] [EXT] Re: 16-bit floats {External} {External}

Thu Aug 7 11:29:48 EDT 2025

Hi all,

I think we’re still waiting to see a few use cases for 16-bit floats. Either they will be persuasive to the group, or they won’t be. I have no philosophical antipathy to supporting new data types in FITS images or tables, but such support does cost the community not-insignificant effort, including revised documentation. Is this particular change to the standard worth the expense?

Imagine the change were made tomorrow. Which projects would adopt the new data type(s) in the near future? What future technologies would be enabled? I am genuinely interested to know what new tricks FITS can be taught.

There is nothing magic about IEEE floats (of whatever precision) or 2’s-complement integers. The FITS checksum is an ASCII-encoded 1’s-complement number, and Rice compression even uses unary numbers. Indeed, ASCII itself is now a flavor of UTF-8, a way to express Unicode. Perhaps FITS should allow UTF-16? Back in the day, IRAF strings were two-byte representations for portability. (Still are, I guess.) Fixed point numbers are even still an option.

Give us a couple of good use cases for 16-bit floats. We’ve heard that IEEE is drafting a standard for Machine Learning which includes small floats (perhaps even smaller than 16-bits). How would users benefit from FITS interoperating with this standard? Do we need IEEE to finish first?

And it might be interesting to consider how 16-bit floats would interoperate with floating-point tile compression. FPACK might read in a 32-bit image array with some aggressive q-scaling (for instance), while FUNPACK could provide the option to write out a 16-bit image. Note that both input and output images would be bigger than the intermediate tile-compressed bintable representation. (The default q of 4.0 corresponds to about 6-bits per pixel.) Or maybe FPACK would support converting 32-bit images directly to 16-bits with a noise-sensitive threshold of some sort.

Rob

On 8/7/25, 7:25 AM, "fitsbits" wrote:

________________________________
We can then use the same argument for 32 and 64-bit floats. Why do we need them, if we can use 32 and 64 bit integers with a scale and offset?

 -- Paul

On Thu, Aug 7, 2025 at 9:39 AM Arnold Rots <arots at cfa.harvard.edu<mailto:arots at cfa.harvard.edu>> wrote:
But why not use an 8 or 16 bit integer with a scale factor and zero offset?

Arnold H Rots

Research Associate

SAO/HEAD

Center for Astrophysics | Harvard & Smithsonian

Email: arots at cfa.harvard.edu<mailto:arots at cfa.harvard.edu>

Office: +1 617 496 7701 | Cell: +1 617 721 6756

60 Garden Street | MS 69 | Cambridge, MA 02138 | USA

[Image removed by sender.]

cfa.harvard.edu<http://cfa.harvard.edu> | Facebook<http://cfa.harvard.edu/facebook> | Twitter<http://cfa.harvard.edu/twitter> | YouTube<http://cfa.harvard.edu/youtube> | Newsletter<http://cfa.harvard.edu/newsletter>

On Sat, Jul 26, 2025 at 8:55 PM Barrett, Paul via fitsbits <fitsbits at listmgr.nrao.edu<mailto:fitsbits at listmgr.nrao.edu>> wrote:
The quick answer is that most telescope backends have 8-bit A2D converters, so 16-bit floats provide sufficient range and precision to store the calibrated data. If you need extended range, then a scaling factor can be used.

 -- Paul

On Sat, Jul 26, 2025 at 7:49 PM Eric Greisen via fitsbits <fitsbits at listmgr.nrao.edu<mailto:fitsbits at listmgr.nrao.edu>> wrote:
I am perhaps the person with the longest exposure to FITS.  I expect that adding 16-bit floats would do little  harm.  But I have not seen a proper exposition of why it is needed.  And I have 50+ years of writing radio astronomy software.  At this stage I would vote against it until a proper set of examples are described.

Eric Greisen
________________________________
From: fitsbits <fitsbits-bounces at listmgr.nrao.edu<mailto:fitsbits-bounces at listmgr.nrao.edu>> on behalf of William Pence via fitsbits <fitsbits at listmgr.nrao.edu<mailto:fitsbits at listmgr.nrao.edu>>
Sent: Saturday, July 26, 2025 1:11 PM
To: Fitsbits <fitsbits at listmgr.nrao.edu<mailto:fitsbits at listmgr.nrao.edu>>
Subject: Re: [fitsbits] [EXT] Re: 16-bit floats {External} {External}

[Have had technical difficulties posting here; here’s another attempt.]

Based on the discussion so far I am inclined to support adding the 16-bit floating point format to FITS, but not the 128-bit format, as a fundamental datatype in images and binary table columns. As a reminder, the numerical range of the float16 datatype is limited to +65504 to -65504 and the precision is limited to about 4 decimal digits.  That means the largest values (in the range of about 32000 to 65500) are only precise to +/- 32, i.e. the largest possible value is 65504 and the next smaller allowed values are 65472, 65440 and so on.   Based on my own experience in optical and Xray astronomy I can’t think of many applications (or any in fact) where this float16 datatype would be appropriate to use. Apparently it could be useful for some radio astronomy data however.

Bill

_______________________________________________
fitsbits mailing list
fitsbits at listmgr.nrao.edu<mailto:fitsbits at listmgr.nrao.edu>
https://listmgr.nrao.edu/mailman/listinfo/fitsbits<https://listmgr.nrao.edu/mailman/listinfo/fitsbits>
_______________________________________________
fitsbits mailing list
fitsbits at listmgr.nrao.edu<mailto:fitsbits at listmgr.nrao.edu>
https://listmgr.nrao.edu/mailman/listinfo/fitsbits<https://listmgr.nrao.edu/mailman/listinfo/fitsbits>
_______________________________________________
fitsbits mailing list
fitsbits at listmgr.nrao.edu<mailto:fitsbits at listmgr.nrao.edu>
https://listmgr.nrao.edu/mailman/listinfo/fitsbits<https://listmgr.nrao.edu/mailman/listinfo/fitsbits>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/fitsbits/attachments/20250807/e287ae45/attachment-0001.html>