request for advice…
Michael wrote on Sep 10, 2007
Sumner, New Zealand
2007 September 10
IRAF Support
iraf@noao.edu
Dear Sir:
I am writing to request help with two problems that I have encountered using IRAF:
o I am unable to use a median .fts flat created with imcomb to flatten .fts images using
ccdproc. The error message I get says, it cannot open the image to be flattened. We are
wondering here if the problem might be ccdproc being too fussy in reading the .fts header, but
we don't really know. Is it possible for me to send the two problem images for examination?
o On the other hand, I have no problem flattening the same images if I use imarith with
simple division. Might there be subtle reasons why imarith cannot be used instead of ccdproc in
order to circumvent the problem?
Thank you for any help you can provide.
Sincerely,
Michael Snowden
mss14@ext.canterbury.ac.nz
cc: Paul Warhurst
Post generated using Mail2Forum (http://www.mail2forum.com)
2007 September 10
IRAF Support
iraf@noao.edu
Dear Sir:
I am writing to request help with two problems that I have encountered using IRAF:
o I am unable to use a median .fts flat created with imcomb to flatten .fts images using
ccdproc. The error message I get says, it cannot open the image to be flattened. We are
wondering here if the problem might be ccdproc being too fussy in reading the .fts header, but
we don't really know. Is it possible for me to send the two problem images for examination?
o On the other hand, I have no problem flattening the same images if I use imarith with
simple division. Might there be subtle reasons why imarith cannot be used instead of ccdproc in
order to circumvent the problem?
Thank you for any help you can provide.
Sincerely,
Michael Snowden
mss14@ext.canterbury.ac.nz
cc: Paul Warhurst
Post generated using Mail2Forum (http://www.mail2forum.com)
Mike Fitzpatrick wrote on Sep 10, 2007
Michael,
Frank may comment further, but I think part of the answer is in an earlier reply of his:
In your case you need to check not only your setting of 'imtype' (used to set the default type of new images if no extension is given explicitly), but also that the 'imextn' allows ".fts" as a valid extension (do a 'show imextn" to check). The problem may also be that in part that the '.fts' extension is being mangled to a ".fits" extension in the processing as described above. You can change all the .fts extensions to .fits using a command such as
Hope this helps.
Cheers,
-Mike
Frank may comment further, but I think part of the answer is in an earlier reply of his:
It can confuse programs when the image type changes. CCDPROC typically
works "in-place", meaning a temporary image holds the processed image
until successful completion and then it replaces the input image.
Because you must have the "imtype" environment variable set to "fits"
it creates a fits a temporary fits output. The replacement is simply
a move so the image type is not changed back to imh. If you have specified
the input as something like *.imh, the next time it wants to access the
image it looks for a imh which it doesn't find because now it is fits.
This would typically happen when a dependent calibration image is processed
automatically before applying to the data.
In short, CCDPROC does not like to work with input in one format and
"imtype" set to a different type. The solution is to either reset
you input to fits or, easier, "reset imtype=imh" followed by flpr.
In the latter situation everything will be done in imh as you probably
have done before.
In your case you need to check not only your setting of 'imtype' (used to set the default type of new images if no extension is given explicitly), but also that the 'imextn' allows ".fts" as a valid extension (do a 'show imextn" to check). The problem may also be that in part that the '.fts' extension is being mangled to a ".fits" extension in the processing as described above. You can change all the .fts extensions to .fits using a command such as
cl> rename *.fts fits field=extnHope this helps.
Cheers,
-Mike
Last post on Sep 10, 2007