psLib defines a collection of APIs for working with FITS files on disk. These currently wrap the CFITSIO library. This page has notes on the implementation.

GZIP Tile Compression and Ohana/libgfits

Files compressed with CFITSIO Tile compression using the gzip compression method have to be handled in a somewhat surprising way by libgfits. In the tile compression method, a series of compressed data sequences are written as entries in a variable length FITS table column. These are identified by the table header as having 4 bytes per data element. Normally, I would expect to have to do the following steps:

1. read a segment of data from the table
2. byteswap (if needed) based on the size of the data element (in this case 4 bytes)
3. pass the swapped data vector to the uncompression function (in this case zlib's uncompress function)
4. insert the resulting data values into the image in the appropriate location.

For images compressed with cfitsio gzip (at least for 16 input data), I apparently have to:

1. read the data segment from the table
2. strip off the gzip header segment (gfits_gz_striphead)
3. pass the remaining bytes directly to a modified version of the uncompress function (gfits_uncompress) -- this version is copied from uncompress, but passes the value -15 to inflateInit to tell it that the data has had the header stripped already.
4. byteswap the resulting vector based on the bytes/pixel of the output data.

Does this mean I am doing something wrong (ie, I could skip some of this work if I just...?), or does it mean CFITSIO is doing something strange (like byteswapping in the wrong place or messing up the header?). I've update libgfits to handle this issue in r23724.