[fitsbits] 16-bit floats {External}

[Seaman, Robert Lewis - (rseaman)]

Hi Tom and all,

This discussion would benefit from describing explicit science or engineering use cases. Which is to say, how much time and effort is it worth to the FITS community to add this to the standard and to the various libraries and applications? Will current software fail gracefully on encountering 16-bit floats?

There is no reason to tie adopting a 16-bit format to support for 128-bit floats. Talk about both at the same time if folks want, but the decision grid would allow for the adoption of one but not the other (or for the adoption of neither). Alternatively, we could expand the discussion to embrace all possible data types and data structures, both for multidimensional image arrays and in binary tables, and the resulting implications for data compression, for instance.

“I am curious” is one of the best motivators for talking about things, but not for changing the standard. What is the justification for this specific proposed change to the standard? Writing this up as a brief, quasi-formal proposal with its pros and cons would be a useful exercise.

Statements like “16-bit floats would perform a lot better” and “16-bit floats would perform a lot better than using compression on 32-bit floats” need to be supported in such a proposal. Are these statements true? For all chipsets, operating systems, programming languages, libraries, applications, use cases? Can the performance (speed and size) be quantified? What does “a lot better” really mean? For example, JPEGXL offers the possibility of larger compression ratios than RICE, but it is slower.

And statements like “16-bit floats would allow a larger dynamic range than using 16-bit ints with BSCALE/BZERO” call out for exploration of the edge cases and are worth maybe a figure or two in the proposal.

Does anybody have a copy of IEEE 754-2008? It’s otherwise behind a paywall: https://ieeexplore.ieee.org/document/4610935

Does anybody here regularly use 16-bit floats? Under what circumstances, for what projects? Images or binary tables? Has their lack in FITS been an impediment to realizing a project’s full potential?

And finally, even in the few messages so far in this thread, there have been arguments built on top of the original vision of FITS purely as an interchange format, and others built on the evolution of FITS into an archival format. The two kinds of format don’t necessarily benefit from the same features or suffer from the same bugs.

And finally, finally, discussions like this and about JPEGXL demonstrate that we need to revive the IAU FITS WG.

Rob




On 7/23/25, 5:36 AM, "fitsbits" wrote:


External Email

________________________________
Hi everyone,

As far as I understand, IEEE 754-2008 standardized the representation of 16-bit floats (as well as 128-bit floats). I was curious whether there is any interest in extending the FITS format to allow BITPIX=-16 and BITPIX=-128?

I am aware of some modern projects that would benefit from having 16-bit floats, since they consider it to be sufficient in precision to store very large datasets, and using 16-bit floats would perform a lot better than using compression on 32-bit floats for example, and 16-bit floats would allow a larger dynamic range than using 16-bit ints with BSCALE/BZERO.

I'm curious to hear if this has been discussed before!

Thanks,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/fitsbits/attachments/20250724/892fd3e6/attachment-0001.html>