Unsigned integer support in NOST 100-1.2

[Phil Hodge]

Bill Pence wrote:

> In the previous debate a few years about about adding new unsigned
> integer datatypes to FITS I had argued in favor of the proposal. 
> However, I have since come to appreciate that the current FITS format
> already fully supports unsigned integers (16 and 32 bit at least), hence
> I would now oppose any change to the Standard in this regard.  FITS is
> able to store unsigned 16 and 32 bit integers in an efficient format
> that is easy to read and write.  This is all that is required.  The
> transformation between the internal FITS representation and the  machine
> representation on a particular computer of the same unsigned integer
> value is trivial: flip the value of the most significant bit (bit 32 or
> 16) and also swap the order of the bytes on little endian machines like
> IBM PCs.  

This is trivial to implement, yes, but it's not transparent to many
people who would read the header.  It's rather esoteric, in fact.
I think that FITS should support unsigned 16-bit and 32-bit integers
using notation (e.g. a DATATYPE keyword) that would be clear to an
intelligent person who is not necessarily an expert on FITS.

Rob Seaman wrote:

> Perhaps rather than worrying about unsigned integers (or 24 bit ints or
> whatever), we should get back to devising a speedy FITS compression scheme
> that would allow using 32 (or even 64) bit integer pixels for intermediate
> precision data in a space-efficient manner.

Would that be 32-bit unsigned pixels?

						Phil