Problem/Question re compressed FITS

[mark.munkacsy]

I recently shifted from uncompressed FITS files to FITS files compressed using the Rice algorithm. Although AstroImageJ (3.4.0.25) appears to read the compressed files (no warnings are generated), the resulting uncompressed pixel values in AstroImageJ don't match the original uncompressed file. This seems to happen in all my compressed FITS files. To illustrate and debug, I've been using a dark file that was originally created as a 32-bit integer FITS file, then written in Rice-compressed form using the cfitsio library. In this example 512x512 file that I've provided, the center 8x8 pixel subarray has the following (original) values (using FITS pixel coordinates):

However, AstroImageJ seems to round and set the low-order 7 bits of each pixel value to zero during decompression, so that the entire 8x8 center pixel subarray has the value 128 when this image is read by AIJ. This really messes up photometry. Both ds9 and the cfitsio library read and write this file preserving all the bits in each pixel; it's only AIJ that does it differently.
Am I wrong for expecting AIJ to handle this file cleanly? Is there some switch or option I need to set to get AIJ to read this the same way that ds9 does?

[karenacollins]

Hi Mark,

The underlying ImageJ that AIJ uses only supports 16 bit integer and 32-bit floating point files (and 8 bit and RGB files). Is it possibly for you to generate compressed 32-bit floating point files instead? As FYI to us, are integers > 65535 actually produced by your camera/detector? If not, we could look at potentially converting the 32-bit integer files to correct 16-bit integer files when being read into AIJ, if a large number of these files are already existing and need to be processed.

Karen

[mark.munkacsy]

Oh!...

(Perhaps I've been spending too much time with teen students. I took AIJ's "failure to complain out loud" as an indication that AIJ was happy.)

Never occurred to me that this was a 32-bit integer problem. This particular camera generates 16-bit images, but another 16-bit camera I use is usually binned 4x4, requiring 20 bits if I want to preserve the full dynamic range. Since a 32-bit, tile-compressed image is almost exactly the same size as a 16-bit, tile-compressed image, I got into the habit of storing everything as 32-bit integer (compressed) images. I've got a format conversion tool, so it's easy for me to shift these images to a more AIJ-friendly format.

Thanks!

[karenacollins]

We will convert 32-bit integer files into 32-bit float (double) images in AIJ v5. That should work for most situations. I agree that the current version should throw an error message when opening 32 bit integer files, but we are focusing our time on v5 at the moment to get it out as quickly as possible.