Problem with all tasks
dufourf wrote on Dec 22, 2010
Hi,
I just installed IRAF on Ubuntu 10.04 64 bits from the lnux.x86_64 binaries.
When I attempt to do anything with a FITS image, all pixel values are read as 0...
For instance, using imstat on a file that I also examined using CIAO's ds9 statistics tool:
In CIAO: min= -236.5 max=30955
in IRAF: min=0 max=0, stddev=0, rms=0 (you get the idea)
DS9 loads everything fine, so the FITS probably isn't to blame.
I must assume that I did something wrong in the installation. What can make this situation happen?
I just installed IRAF on Ubuntu 10.04 64 bits from the lnux.x86_64 binaries.
When I attempt to do anything with a FITS image, all pixel values are read as 0...
For instance, using imstat on a file that I also examined using CIAO's ds9 statistics tool:
In CIAO: min= -236.5 max=30955
in IRAF: min=0 max=0, stddev=0, rms=0 (you get the idea)
DS9 loads everything fine, so the FITS probably isn't to blame.
I must assume that I did something wrong in the installation. What can make this situation happen?
Mike Fitzpatrick wrote on Dec 22, 2010
The first thing to try is to see whether it is all FITS images, or just the ones you're using, e.g.
If that shows real pixel values then it may be something local to your data (e.g. multiple BSCALE keywords) in which case I'd ask that you upload a sample image to the anonftp at ftp://iraf.noao.edu/pub so I can have a look. It's not an installation problem I can think of, if it were the tasks wouldn't run at all.
cl> imcopy dev$pix foo.fits
cl> imstat foo.fits
If that shows real pixel values then it may be something local to your data (e.g. multiple BSCALE keywords) in which case I'd ask that you upload a sample image to the anonftp at ftp://iraf.noao.edu/pub so I can have a look. It's not an installation problem I can think of, if it were the tasks wouldn't run at all.
dufourf wrote on Dec 22, 2010
I did try the example with non-zero results, but I also tried the problematic files with another installation of source-compiled Debian 32 bits IRAF 2.15, and the same frames didn't do anything peculiar (apart from being extragalactic, but that's another topic).
I am also surprised that standard UKIRT WFCAM files would have a problem, which is why I suspect something on my side.
I am also surprised that standard UKIRT WFCAM files would have a problem, which is why I suspect something on my side.
Mike Fitzpatrick wrote on Dec 22, 2010
Could you upload a sample image, otherwise I've got nothing else to go on.....
dufourf wrote on Dec 22, 2010
I uploaded a sample frame from the problematic images at ftp://ftp.noao.edu/pub/upload/w20061205_00830.fit .
I daresay the header looks normal...
I daresay the header looks normal...
Mike Fitzpatrick wrote on Dec 22, 2010
I've got the image and can reproduce the problem on a linux64 system. The datatype is 'double' which I suspect is the cause. I'll get back to you when I track it down .....
Last post on Dec 22, 2010