Segmentation Violation for a .imh image
stevenford17 wrote on Mar 25, 2008
I would love to hear from anyone who can comment on and help me fix this error that I received while trying to bring up a subtracted image. Basically, I subtracted one image from another and created a new file. When I try to bring up that file using "implot sub019a" it gives me a segmentation error. I am using Fedora and v2.14. The new file is in the same directory as the original images. Any thoughts? Thanks in advance.
Mike Fitzpatrick wrote on Mar 25, 2008
A segfault is usually a coding error, but in some cases can be caused by the data. Does an IMSTAT on the image manage to read it successfully or do you see a similar segfault. Did you do the subtraction with IMARITH or something else?
If no other task can read the image either then it's the data: You can force the image to be a different format using e.g.
If you can then implot/imstat the 'result.fits' check your 'imdir' variable: This is where the .pix files for IMH format images are stored and in your case may not be valid or writable.
OTOH if it's only implot that's failing, please post a url to the image or put it in the anonftp at ftp://iraf.noao.edu/pub and I'll try to reproduce the problem.
Cheers,
-Mike
P.S. Also be sure you're using the Jan14 critical update mentioned on the homepage, that usually causes a different error but better to check anyway.
If no other task can read the image either then it's the data: You can force the image to be a different format using e.g.
cl> imarith im1 - im2 result.fitsIf you can then implot/imstat the 'result.fits' check your 'imdir' variable: This is where the .pix files for IMH format images are stored and in your case may not be valid or writable.
OTOH if it's only implot that's failing, please post a url to the image or put it in the anonftp at ftp://iraf.noao.edu/pub and I'll try to reproduce the problem.
Cheers,
-Mike
P.S. Also be sure you're using the Jan14 critical update mentioned on the homepage, that usually causes a different error but better to check anyway.
stevenford17 wrote on Mar 25, 2008
I used IMARITH to do the image subtraction (a .fits file minus a .fits file). IMSTAT gives a "cannot read or open" fault. When I save the file as a .fits image, I can open it, but this doesn't help as I need it in a .imh format for the APALL commands I need to do.
My "imdir" is defined, but not as the file in which my data is saved. Is that a problem?
I posted the 'spec019a.imh' image file on the FTP you posted in hopes that we can figure this out... thanks for your help!
-Steve
My "imdir" is defined, but not as the file in which my data is saved. Is that a problem?
I posted the 'spec019a.imh' image file on the FTP you posted in hopes that we can figure this out... thanks for your help!
-Steve
Mike Fitzpatrick wrote on Mar 25, 2008
The image you posted has the pixel file has just an empty string, i.e. what you have is a header but no pixels.
What *is* the value of your 'imdir' variable (i.e. "cl> show imdir")? Is this a directory you can write to and that actually exists?
A simple test is to rest the imdir to something known like the directory where the image is being created:
You can reset the imdir by editing your login.cl file, note that a value like "HDR$pix/" (trailing '/' required!) will create a 'pix' subdirectory and put the pixel files there.
-Mike
What *is* the value of your 'imdir' variable (i.e. "cl> show imdir")? Is this a directory you can write to and that actually exists?
A simple test is to rest the imdir to something known like the directory where the image is being created:
cl> reset imdir = "HDR$/"
cl> flpr 0 # zero, not oh
cl> imarith one.fits - two.fits result.imh
cl> imstat result.imh
You can reset the imdir by editing your login.cl file, note that a value like "HDR$pix/" (trailing '/' required!) will create a 'pix' subdirectory and put the pixel files there.
-Mike
stevenford17 wrote on Mar 25, 2008
Looks like that did it. Thanks for your prompt and helpful replies!
-Steve
-Steve
Last post on Mar 25, 2008