Changes between Version 1 and Version 2 of FITS_Interface_in_PSLib

Timestamp:

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

Author:

eugene

Comment:

--

FITS_Interface_in_PSLib

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