Summary

The ASCII encoded 1's complement checksum has several features that make it a good choice for safeguarding FITS data:

• The checksum of each FITS HDU is forced to zero by writing the complement of the calculated checksum into the header. Verifying a particular HDU requires only that the checksum computes to zero.
• If the checksums of all HDUs in a FITS file are zeroed, the checksum for the entire file will be zeroed. All HDU's in such a file can be verified by accumulating a single checksum.
• Since 1's complement addition is commutative and associative, the checksum may be accumulated in any order.
• Specifically, this means that the checksum is transparent to the byte order of any particular machine architecture.
• The checksum is straightforward to update as the header or data records are changed during a sequence of processing steps. Since the checksum is incrementally updated, the end-to-end nature of the verification is maintained.
• A simple rearrangement of keywords leaves the checksum unchanged.
• The checksum of the data records is written into a separate header keyword, DATASUM, and is not recomputed unless the data records are modified. The DATASUM keyword is not ASCII encoded as with the CHECKSUM keyword, but is rather formatted as an unsigned integer valued character string.
• Individual FITS extensions have separate checksums. Extensions with zeroed checksums may be added and removed from a larger FITS file without disturbing the aggregate checksum.
• The recipe for updating the CHECKSUM keyword following some change to the file is: , where C and C' represent the file's checksum before and after the modification, m and m' are the corresponding checksums for the modified FITS records or keywords only, and (tilde) denotes the (1's) complement operation.