[fitsbits] Output array type when BZERO is an integer {External}

[William Pence]

To clarify, the way that FITS stores unsigned integers (using a special BSCALE or TSCALn value) was specified in the original FITS definition papers and is not just a CFITSIO convention. 

Almost exactly 30 years ago, Arnold Rots proposed that support for native unsigned integer datatypes should be added to FITS, which lead to a long discussion on fitsbits (see the archive for February, March, and April 1994 here: https://fits.gsfc.nasa.gov/fits_fitsbits_archive.html).  I initially supported this proposal, but later came to agreed with others that it does not  matter how unsigned integer values are encoded in a FITS file as long as the convention is clear and unambiguous.   What does matter is that the interface that programmers use to read and write FITS file should provide transparent support for unsigned integers. The programmer simply calls the appropriate interface routine to read or write an array of native unsigned integers and the interface library efficiently handles all the necessary conversions (including byte swapping if needed on that computer platform) to the string of bits in the FITS file. 

Bill

> On Mar 28, 2024, at 6:11 AM, Richard J. Mathar via fitsbits <fitsbits at listmgr.nrao.edu> wrote:
> 
> jp> Date: Wed, 27 Mar 2024 16:23:18 -0700
> jp> From: John Parejko <parejkoj at uw.edu>
> jp> To: Jonas <jonas.repo at protonmail.com>
> jp> Cc: "fitsbits at listmgr.nrao.edu" <fitsbits at listmgr.nrao.edu>
> jp> Subject: Re: [fitsbits] Output array type when BZERO is an integer
> jp>         {External}
> jp> ...
> jp> uint64 images being only supported by cfitsio convention has been an annoyance for us in the past. It really should be supported
> jp> natively in FITS.
> 
> I think that the Java reference implementation of nom.tam.fits
> also supports the 64bit image type. (Search for VALUE_FOR_LONG in the source
> code.) https://github.com/nom-tam-fits/nom-tam-fits .
> In the particular case of the Java language (unlike C or python) the
> number of bytes in the integer classes are of fixed, known IEEE length,
> which makes life slightly easier to a programmer. The newer FORTRAN
> languages also have ways to bind integer types to representations of strictly
> known lengths.
> 
> The complex data type (spinors? magnetic fields?)
> is apparently not yet supported in nom.tam.fits . The idea of quaternions
> (4 values, Dirac equations of bispinors etc) has not yet been introduced into
> the FITS standard.  Support of UUID's would need 128 bits....
> 
> Richard Mathar
> 
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/fitsbits