iraf.net

Hello,I have a set of fits images that v2.15 (64bit version on 64bit F16) wouldn't display. It just returns SEG. FAULT. This is the header of the images:[quote:afabd20fe8]
SIMPLE = T / file does conform to FITS standard
BITPIX = 32 / number of bits per data pixel
NAXIS = 0 / number of data axes
EXTEND = T / FITS dataset may contain extensions
COMMENT = ' '
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
BZERO = 2147483648 / offset data range to that of unsigned long
BSCALE = 1 / default scaling factor
[/quote:afabd20fe8]I can 'ccdlist' but not display, imexax, etc. The same images are perfectly well display with v2.14 which I run on another machine. These are raw unprocessed image. Another set of raw images:[quote:afabd20fe8]
SIMPLE = T / A valid FITS file
BITPIX = 16 / [bits] Bits per pixel
NAXIS = 2 / Number of axes
NAXIS1 = 1080 / [pixels]
NAXIS2 = 1024 / [pixels]
BZERO = 32768.0000000 / Number to offset data values by
BSCALE = 1.0000000 / Number to multiply data values by
[/quote:afabd20fe8]are however perfectly well displayed with v2.15. Talking to colleagues, I had the impression that many have encountered problems with certain images and the 64bit version of v2.15, but I could not find a related post in the forum. Anyone has have similar issues?

Vall,
It looks to me as if the header has missing data. The naxis values is zero, and naxis1 and naxis2 do not exist. Without this information the display software has no way to break up the stream of values into x,y positions.Jim

No, it is multi-extension FITS file. I can process it and do whatever with IRAF v2.14, but not with v2.15 64bit.

This problem was recently fixed in the development system, the 4-byte integers weren't being properly unpacked to native ints when scaling is used in the FITS kernel. You didn't say whether this was a Linux or OSX system and I'm travelling at the moment but unless you want to patch and update the source locally a full set of binaries is required to properly fix this.If you're interested let me know and I'll post instructions.

[quote:52e018421c="fitz"]This problem was recently fixed in the development system, the 4-byte integers weren't being properly unpacked to native ints when scaling is used in the FITS kernel. You didn't say whether this was a Linux or OSX system and I'm travelling at the moment but unless you want to patch and update the source locally a full set of binaries is required to properly fix this.If you're interested let me know and I'll post instructions.[/quote:52e018421c]Yes, I am interested. I use Fedora 16 64bit Linux. Thanks.

The file to get (depending on the platform) isftp://iraf.noao.edu/iraf/v215/support/linux64/libex.a
or
ftp://iraf.noao.edu/iraf/v215/support/macintel/libex.aInstall this file in your $iraf/bin.linux64 (or $iraf/bin.macintel) directory.To relink your system with the new library: 1) Edit your .cshrc file to define the needed environment: setenv iraf /iraf/iraf/
setenv IRAFARCH linux64
source $iraf/unix/hlib/irafuser.csh Be sure the trailing '/' is on the iraf pathname, and that the
path is appropriate for your system 2) Go to your iraf root directory and change the system arch: % make linux64 3) Relink the system % make updateYou'll need to similarly relink external packages to also pick up the change, e.g. % cd $iraf/extern/fitsutil
% mkpkg -p fitsutil linux64
% mkpkg -p fitsutil updateDetails may vary depending on the package, if you have problems post 'em here.

thinks. It works now. The updates also worked for all the external packages but TABLES and STSDAS. These two have no .bin.linux64' directories. Should I updates them with 'mkpkg -p tables linux' or there is no need for that?

Only 64-bit architectures need to be updated, STSDAS/TABLES will remain 32-bit according to STScI and the system will simply use those binaries as needed.

I have also done what has been suggested, but I am still finding problems with displaying an image with ds9 and still get a segmentation violation. I should be running the linux64 architecture now. The only problem I encountered along the way was that when I originally typed:[quote:ddac48400e]make linux64[/quote:ddac48400e]Then it could not find the file "$iraf/extern/.zzsetenv.def"To get round this I copied it from /iraf/iraf/local/lib/zzsetenv.def (note the is no preceding dot) to the extern dir.This file contains:[quote:ddac48400e]
#Global environment definitions for the LOCAL packages.#set localbin = "local$bin(arch)/"
set localbin = "local$bin/"
set pkgbin = localbin$
set pkglibs = local$lib/keep
[/quote:ddac48400e]Could this have anything to do with it not working?

The error is that the $iraf/extern/.zzsetenv.def file was removed for some reason. You can reset the entire extern directory with a "make init" command in $iraf/extern, this assumes you've already run the configure script to create the Makefile (if not, then "./configure" will create one and init the .zzsetenv.def file as well).If the .zzsetenv.def was deleted then there may be other problem with the extern directory as well so a 'make init' might be needed anyway. Your workaround fixed the problem because then at least *something* was in that file, even though it had no real effect.

Thanks for that. I ran ./configure and make init with no problem. But I still seem to be experiencing a segmentation violation when trying to display this image. Is there some sort of logfile I can check to see what is happening?

Could you upload the image to the anonftp at ftp://iraf.noao.edu/pub so I can try to reproduce it here? Are you using MSCDISPLAY on the whole MEF or DISPLAY on individual extensions? Any parameters set like 'fill'?

Sure, it is uploaded and called ukidss_iraf2.fits. I am just using display (into ds9),
[quote:1d26e27eab]display ukidss_iraf2[1] 1[/quote:1d26e27eab]
but I have also tried it on a single extension version of the same file and no luck with that either. There are no extra parameters.

Also, I've just noticed that the same is happening when I run it for ximtool! - I have the 24-bit display version installed. :-s

The problem was with the use of BITPIX=32 data having bscale/bzero values in the header. The earlier fix worked correctly on macintel systems, but for reasons I don't fully understand, was having alignment issues under linux leading to the segfault seen.I can give you individual patched binaries but the bug affects all tasks and so the system should be relinked with the patch. The files you'll need to get areftp://iraf.noao.edu/iraf/v215/support/linux64/libex.a
ftp://iraf.noao.edu/iraf/v215/support/linux64/libvops.aInstall these in your $iraf/bin.linux64 directory and relink as described above. Let us know if you still have problems.

Still no luck I'm afraid. I'm getting the same violation from both ds9 and ximtool.

I verified that the patched binaries were correct in the archive and indeed fix the DISPLAY task for your image. Can you verify that the $iraf/bin.linux64/x_tv.e binary was indeed updated after you relinked with the new libraries? In cases like this the usual problem is that the system wasn't reconfigured for the proper architectre (linux64), or there was a missing environment definition or some other error that kept the binary from compiling properly.Since the bug affects all tasks you'll need a new set of binaries relinked against the patched libs, but in case it helps I've put the DISPLAY binary with the fix atftp://iraf.noao.edu/ftp/v215/support/linux64/x_tv.eInstall this in $iraf/bin.linux64 and let me know if you still have problems.

It looks like x_tv.e wasn't updated after the link as I put the binary in bin.linux64 and it works with no problems.
Thanks for your help1