On Mon, 5 Mar 2007, Matt Auger wrote:
> Ok...other users on my system didn't have the problem with the same build of
> starlink, leading me to further investigate my own environment. In the end I
> was able to resolve the issue with the gaiatest.fits file by removing the
> .skycat directory in $HOME, though in the process I also destroyed any
> evidence for what was causing the problem in the first place....
Hi Matt,
that's a shame, would have been nice to understand exactly what happened
there. There have been the occasional issues raised by having a corrupt
"~/.skycat/history" file, that might have fitted the error (so that the
wrong number of dimensions are given).
> The question remains why gaia isn't dealing with the absent CRPIX3 keyword
> correctly in the gaiacrash.fits test, but at least there is an easy work
> around (ie externally ensuring that the header is present).
This is a problem in GAIA dealing with the case when the number of WCS
axes are less than the number of cube axis. I've tracked down the
offending code and corrected it.
Note that when you just have a CRPIX3 value and no associated CD value,
that CD value actually defaults to 0 (FITS standard), hence the bad values
reported for that axis, not just a linear axis as you might expect. Also
(as Tim said) floating point FITS uses NaN as the bad value, so that's
what you'll see when dealing with simple FITS images. However, when you
load a cube GAIA works hard to be efficient, which means that the image
you see is really an NDF, not a FITS image, hence those bad values will be
reported as blank, not NaN, as the NDF format uses a special value for
bad. If you're dealing with large cubes then it is more efficient to
convert those to NDF format first.
Cheers,
Peter.
--
Dr. Peter W. Draper, http://star-www.dur.ac.uk/~pdraper
|