Discussion

The basic idea is the same as used by the Internet checksum (ref. 12-14). An unsigned integer is embedded within each data packet (FITS header) which forces the 1's complement checksum of the entire packet (FITS HDU) to zero. To find this integer, zero the checksum field in the packet and accumulate the checksum--the necessary value is just the complement (additive inverse) of the checksum.

A 1's complement checksum (as used by TCP/IP) is preferable to a 2's complement checksum (as used by the Unix sum command, for example), since overflow bits are permuted back into the sum and therefore all bit positions are sampled evenly. A 32-bit sum is as quick and easy to calculate as a 16 bit sum due to this symmetry, providing greater sensitivity to errors (see §4).

In this proposal, the equivalent of zeroing the checksum field is to set the 16 character string value of the CHECKSUM keyword to all ASCII 0s (hex 30). The checksum is then accumulated in FITS storage order over the header and data records of each separate FITS HDU. These HDUs are either the individual extensions of a larger FITS file, or are just the primary HDU (whole file) for a simple FITS file. The (1's) complement is then formed for the resulting checksum. Finally, the complemented checksum is ASCII encoded and then written into the header replacing the ASCII 0s, which are in effect subtracted back out of the encoding to restore the original value. The HDU's previous checksum and its embedded complement now sum to zero. Alternate interpretations of this encoding algorithm are possible, see §3.6.