-
When I copy a science (data) extension from a WFC3 MEF fits file to a single extension fits file, and then copy it back to the same extension in the same file, it appears that the header has changed in some way that causes subsequent tasks to fail. Specifically, I am copying a science extension out to its own file, running LACosmic, then putting the cleaned data back in place in the original image file. Even though the data look good, and things like DS9 have no problem with the file, other tasks in drizzlepac gag on the file, apparently because the WCS has been altered in some way. Is there a workaround? Or what am I doing wrong? Thank you, |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
Can you provide a small but complete example that shows the problem? |
Beta Was this translation helpful? Give feedback.
-
Here is an example, with image.fits being the standard wfc3 MEF file, which is a single exposure and has lots of CRs. The image pixels are in extensions 1 and 4 (or SCI,1 and SCI,2).
Then I run LA_Cosmic on each sci0*.fits to remove the CRs. (Unfortunately I have to use the IDL version since LA_Cosmic in iraf needs tools from STSDAS. This may in fact be part of the problem, see below.) Now copy these back into the original image.fits:
The actual pixel data appears to be the same size and format at each step. Correcting this would be an IDL LA_Cosmic issue, of course. Meanwhile, though, is there a way to use imcopy (or something else in iraf) to move just the pixel data from the CR-cleaned output back into the WFC3 MEF file, without also copying the headers? Thanks for the help. |
Beta Was this translation helpful? Give feedback.
Why are you using IRAF here at all? IMO Astropy should easily do the job. Like:
I would really take any chance to move away from IRAF and to use modern tools instead of a lengthy search how this could be done there.