iraf.net

Dear all IRAF users,
I have been dealing w/ optical images from KPNO 2.1 m.
As you knew, fits files from 2.1m do not have any information of WCS.
While I have been suggested to use tasks from immatch package, I somehow
fell in love w/ msccmatch since, if you knew where you are looking, msccmatch
provides very convenient feautres, which almost feels like 'point-and-shoot.'
Therefroe what I have done w/ 2.1 m fits files were
1) edit their CRPIX and CRVAL w/ approximate RA/DEC and pixel positions,
2) edit CD1_1, 1_2, 2_1 and 2_2 to their axis linining up w/ rough orientation (N&E), and
3) run msccmatch.The problem is, msccmatch changed the default coordinate system.
I certainly editted CTYPE1 and 2 as RA---TAN and DEC---TAN before running it and it shows fine when I loaded those fits files into DS9. After going through msccmatch, CTYPE1 and 2 are editted into LINEAR. So, yes, I can't run msccmatch again on them and DS9 does not show RA and DEC.Still, when I 'mscdisplay'ed them and 'msctvmark'ed coordinates which msccmatch used to do matching job, they are all in right places.My question is, is there any IRAF task for me to convert coordinates, or header parameters to show RA and DEC w/ DS9, while believing its WCS info is right?Or, is there anything I have to set before I run msccmatch on single extention fits files?I believe that there should be some way, since whenever I ran msccmatch on MIMO files, it does not change them and those MIMO files all looked good.Thanks a lot.jh

Hi JHI appreciate and agree with you that msccmatch is a nice higher level tool. While an effort was made to make this more general than the mosaic camera for which it was developed there may still be a few unforseen things.Let me give the warning that msccmatch assumes that the starting WCS is only wrong by a x/y shift, possibly a small rotation, and some degree of axes skew caused by differential refraction. The most likely assumption to fail with other cameras is the rotation. However, if the assumptions are met and there are reference stars then it should automate the work of correcting for the telescope errors.I can't see why the final WCS projection type is linear. Looking at the code it should inherit the input image type. If you would like to provide me with a test case I would be glad to try and understand what is going on.I understand your question is about DS9 and fixing the headers. I'm not sure what to recommend other than hedit.Yours,
Frank

Dear Frank,
thanks a lot for your comment.
What could be the best way to hand over you a test case?
I think, fits files before/after and msccmatch parameters should do the case.
(or, do I have to dig up some from immatch package tasks, which are supposed to be called up by msccmatch?)
As I mentioned, they are from KPNO 2.1m+T2KB and about 16MB big.
Thanks again.###############################################################
Now, seems like, I found out why it happens.
Although it makes me look more stupid, I have to post up what I found.When Frank said, 'msccmatch' inherits the system from images, I thought "yes, it should, but how from what?' Yes, I'd been totally ignoring what is supposed to
represent the system, since somehow 'msccmatch' recognizes coordinates on
images, at least for the first time around w/o paying attention to it.Yes, the problem was, at least KPNO2.1+T2KA(and B as well?) gives its fits
files WAT0_001 ~WAT2_001 as WAT0_001= 'system=physical'
WAT1_001= 'wtype=linear'
WAT2_001= 'wtype=linear' so w/ editting them intoWAT0_001= 'system=image'
WAT1_001= 'wtype=tan axtype=ra'
WAT2_001= 'wtype=tan axtype=dec' along w/ right values for CTYPE1 and 2, CD1_1~CD2_2, CRVAL1 and 2,
CRPIX1 and 2, you can run 'msccmatch' on KPNO2.1+T2KA in order to do
astrometry.Thanks, Frank. It was what you said "~inherit~' made me look harder into
headers. I should have learned about it harder.jh