Changes between Initial Version and Version 1 of FITS_Interface_in_PSLib

Timestamp:

Apr 7, 2009, 1:01:20 PM (17 years ago)

Author:

eugene

Comment:

--

FITS_Interface_in_PSLib

@@ +1 @@
+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:
+# read a segment of data from the table
+# byteswap (if needed) based on the size of the data element (in this case 4 bytes)
+# pass the swapped data vector to the uncompression function (in this case zlib's uncompress function)
+# 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:
+# read the data segment from the table
+# strip off the gzip header segment (gfits_gz_striphead)
+# 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.
+# 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.
+
+