<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>(With unknown TFORM, one can still skip the full BINTABLE HDU or<br>
still read columns located before the unknown TFORM column.<br>
One could also skip unknown TFORM columns, but only if the
bintable <br>
contains a single unknown TFORM type.<br>
<br>
That said, I do not expect software to have implemented such
possibilities,<br>
they will probably just raise an error when encountering an
unknown TFORM.<br>
).<br>
</p>
<div class="moz-cite-prefix">Le 28/07/2025 à 11:26, Francois-Xavier
PINEAU a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:6acc31dc-0962-478e-b818-0c823d8f9e62@astro.unistra.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Rust supports both f16 and f128 in its nightly (thus
"experimental)" version:<br>
* <a class="moz-txt-link-freetext"
href="https://doc.rust-lang.org/std/primitive.f16.html"
moz-do-not-send="true">https://doc.rust-lang.org/std/primitive.f16.html</a><br>
* <a class="moz-txt-link-freetext"
href="https://doc.rust-lang.org/std/primitive.f128.html"
moz-do-not-send="true">https://doc.rust-lang.org/std/primitive.f128.html</a><br>
See also the RFC book<br>
<a class="moz-txt-link-freetext"
href="https://rust-lang.github.io/rfcs/3453-f16-and-f128.html"
moz-do-not-send="true">https://rust-lang.github.io/rfcs/3453-f16-and-f128.html</a><br>
pointing to some discussions<br>
<a class="moz-txt-link-freetext"
href="https://hackmd.io/@rust-lang-team/rkSQNidkp"
moz-do-not-send="true">https://hackmd.io/@rust-lang-team/rkSQNidkp</a><br>
It should only be a matter of time before both become standard.<br>
<br>
</p>
<p>But, I wonder if adding new BITPIX/TFORM values in HDUs<br>
already described in the standard (Primary, BINTABLE, ...) does
fit<br>
with the FITS philosophy as it is described here:<br>
<a class="moz-txt-link-freetext"
href="https://fits.gsfc.nasa.gov/users_guide/users_guide/node7.html"
moz-do-not-send="true">https://fits.gsfc.nasa.gov/users_guide/users_guide/node7.html</a><br>
<br>
First paragraph:<br>
"Any FITS reader should be able to cope with any FITS
formatted file,<br>
skipping over portions (extensions) and ignoring keywords
that the reader <br>
does not and need not understand"<br>
<br>
Knowing how to interpret BITPIX and TFORM is mandatory to
compute the byte size <br>
of the data part of a HDU, and thus to be able to skip it.<br>
True that the BITPIX description contains "[t]he absolute value
is used in <br>
computing the sizes of data structures", but there is a list of
"valid" values <br>
and I would expect a lot of implementations to raise an error
when encountering<br>
an undefined BITPIX value.<br>
In addition, there is no way to know the byte size of an unknown
TFORM value.<br>
<br>
Then, true:<br>
"Changes in the FITS rules may add new structures that old
software cannot <br>
handle. Revised software will be required for new standard
extensions [...]"<br>
<br>
but, followed by:<br>
"As far as is possible, however, FITS should be expanded in
such a way that<br>
the old software will still be able to process those parts of
the file which <br>
it is capable of handling. <br>
In such a case, software should not fail or give incorrect
results when <br>
confronted with the new extension or conventions; it should
simply ignore <br>
them and continue to process those parts of the file that it
can <br>
understand."<br>
<br>
"As far as is possible" is open to interpretation, but "new
structures" and <br>
"required for new standard extensions" does not seem to be
compatible (to me) <br>
with *current standard extension* and *new values of already
defined keywords*.<br>
Does the "FITS philosophy" cover the case of breaking changes in
existing extensions?<br>
Should it be reworded or expanded?<br>
<br>
Quite clearly, I expect most (all/a lot of?) software to fail
trying to read a FITS<br>
file with previously not defined BITPIX or TFORM values (as
mentioned <br>
by Preben Grosboel).<br>
<br>
I do understand that defining new extensions to simply add new
BITPIX/TFORM<br>
values seems excessive.<br>
<br>
<br>
Also copying with the question of the real need for f16 (and/or
f128) in FITS,<br>
an alternative could be to start by introducing two new FITS
conventions:<br>
* one generic convention describing how to overwrite existing
keywords values<br>
(OVERWRITE keyword?)<br>
* one specific "half-float" convention introducing BITPIX=-16 /
TFORM=H <br>
and using the generic "overwrite" convention to hide those
values to <br>
unmaintained software.<br>
<br>
An image containing half floats could be described as a flat
byte array in <br>
"regular" FITS (nothing interesting to be read for "half-float"
unaware <br>
readers), and decoded by *overwrite + half-float* aware readers.<br>
<br>
Similarly, in a BINTABLE, a half float column could be a 2B
column for <br>
regular readers and a f16 for *overwrite + half-float* aware
readers.<br>
<br>
Time will let know is those conventions are worth being put in
the standard<br>
or not (or if the introduction of f16 in the standard is worth
breaking <br>
existing software).<br>
<br>
<br>
Maybe defining new conventions here is also excessive.<br>
If so, should the FITS philosophy page be (slightly)
re-worded/extended?</p>
<p>If I remember correctly, long keywords have not been accepted
because:<br>
* it would have break existing software<br>
* the HIERARCH convention already allows to define long keywords<br>
But, if breaking changes like new BITPIX/TFORM values are
accepted, <br>
what about other breaking changes: long keywords, UTF-8 values,
... ?</p>
<p><br>
</p>
<p>I don't have any firm convictions; I'm simply trying to better
understand<br>
the FITS philosophy and to explore the various possibilities.<br>
</p>
<p><br>
François-Xavier Pineau<br>
<br>
</p>
<div class="moz-cite-prefix">Le 23/07/2025 à 22:40, Mohammad
Akhlaghi via fitsbits a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:4BE22817-6B89-4B0F-84C5-5A8B29E11B5B@akhlaghi.org">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<div dir="auto">As mentioned before, it is also available in C:<br>
<br>
<a
href="https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Floating-Representations.html"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Floating-Representations.html</a><br>
<br>
Cheers,<br>
Mohammad<br>
<br>
</div>
<br>
<br>
<div class="gmail_quote">
<div dir="auto">On July 23, 2025 10:22:12 PM GMT+02:00,
"Barrett, Paul via fitsbits" <a
class="moz-txt-link-rfc2396E"
href="mailto:fitsbits@listmgr.nrao.edu"
moz-do-not-send="true"><fitsbits@listmgr.nrao.edu></a>
wrote:</div>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="auto">These formats are available in the Julia
programming language. Adding them to FitsFiles.jl should
take minimal effort, say a few days at most.
<div dir="auto"><br>
</div>
<div dir="auto"> -- Paul</div>
<div dir="auto"><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Wed, Jul 23, 2025,
16:13 Lucio Chiappetti via fitsbits <<a
href="mailto:fitsbits@listmgr.nrao.edu"
moz-do-not-send="true" class="moz-txt-link-freetext">fitsbits@listmgr.nrao.edu</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On
Wed, 23 Jul 2025, Barrett, Paul via fitsbits wrote:<br>
<br>
> Yes, definitely. I have been advocating for
half-precision (16-bit) <br>
> floating point for several years now for radio
astronomy. In addition, <br>
> 128-bit floats<br>
<br>
Are these formats supported by any major programming
language ?<br>
<br>
Is it worth supporting "exotic" formats, which might be
suitable for some <br>
niche application, when most data producers often use
improperly 64-bit <br>
all the times, even when overshoot ?<br>
<br>
Historically FITS went the other way round
(concentrating on 16 and 32, <br>
later 64, when mainframres with 36 or 60 bits were
around).<br>
<br>
_______________________________________________<br>
fitsbits mailing list<br>
<a href="mailto:fitsbits@listmgr.nrao.edu"
target="_blank" rel="noreferrer"
moz-do-not-send="true" class="moz-txt-link-freetext">fitsbits@listmgr.nrao.edu</a><br>
<a
href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><br>
</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
fitsbits mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:fitsbits@listmgr.nrao.edu" moz-do-not-send="true">fitsbits@listmgr.nrao.edu</a>
<a class="moz-txt-link-freetext"
href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits"
moz-do-not-send="true">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a>
</pre>
</blockquote>
</blockquote>
</body>
</html>