Saving/reading recon array leads to different outcomes

[MatthewWhiting]

If you compare the output catalogues from running with reconstruction, and running on a read-in reconstruction, you get subtle differences. The sources are essentially the same, but certain pixels are included or excluded (in fact, on the example I did it was always more pixels for the read-in case).

This is not good.

[MatthewWhiting]

The problem appears to be due to the way we write the reconstructed cube.

The header is copied from the input image to the recon cube (via the cfitsio fits_copy_header function. For the HIPASS case (the usual H201 image that I test on), this means the output cube has BITPIX=16 (short integer). I think this results in unnecessary binning of the output array, so that the values actually get altered.

This is not what we want. When we save the reconstructed array, this should save the actual values in the array, and so the BITPIX value should really be FLOAT (-32).

We can make use of the wcslib function wcshdo to convert the wcsprm struct into a set of header entries - this will include all the WCS-related ones, although not the beam or BUNIT ones. Implementing this would mean we wouldn't have to read the image cube again to get the full header.

[MatthewWhiting]

This is done in [900] and [902]. Have fixed it for all the writing functions, so that they all uniformly use the new writeBasicHeader function. This takes care of the required keywords, the WCS-related ones, plus beam (via DuchampBeam?), BUNIT and (if the bitpix is positive, ie. integral) the BSCALE,BZERO & BLANK keywords.

For 2D images, the spectral dimension is set to 1, but all spectral WCS keywords are still written to the header.

This all solves the main problem in this ticket, in that the results done in both ways are identical.