iraf.net

From: Sam Schmidt <sschmidt@bruno.phyast.pitt.edu>
Date: June 28, 2005 11:01:41 AM MST
To: valdes@noao.edu
Cc: Sam Schmidt <sschmidt@bruno.phyast.pitt.edu>
Subject: IRAF (msccmatch) questionHello,
I have a question about the IRAF task msccmatch, and Andrew
Hopkins here at Pitt referred me to you. We have been using
msccmatch to
register images taken with the FLAMINGOS instrument at Kitt Peak, and
when
I do a cross match of these objects against sdss, there is an offset
of up
to 2 arcseconds in some of the fields when comparing to sdss. At
first I
thought this might be due to the fact that we are matching near-IR
objects
(K band) with optical (sdss), but I had Andrew take a quick look at some
optical (MOSAIC camera, I believe) data that he took for the Phoenix
survey, and it shows an offset of about a half an arcsecond compared to
his radio catalog. It's not a local minima problem or anything, as
msccmatch is very consistent in its solution (rerunning the task usually
gives additional shifts of tenths or hundreths of a pixel shift, so it's
not changing at anywhere near the level of the apparent offset). I have
about a hundred fields (about 10 arcminx10arcmin), and the offset isn't
constant, in fact, some of the fields have the wcs spot on, so I'm not
sure what the problem could be.Has this problem ever been reported before? Unfortunately, the
documentation for the msccmatch task isn't all that great. If you need
any more details of the parameters that we use, I'll stick an example
below. We get the coordinates with mscgetcat from the NOAO:USNO-A2
catalog. If you need to know anything else, let me know. Anything you
could tell us would be greatly appreciated.Thanks,
Sam Schmidt
sschmidt@astro.phyast.pitt.eduPACKAGE = mscred
TASK = msccmatchinput = @outrot.lis List of input mosaic exposures
coords = Coords.list Coordinate file (ra/dec)
(outcoor= ) List of updated coordinate files
(usebpm = no) Use bad pixel masks?
(verbose= yes) Verbose? # Coarse Search
(nsearch= 100) Maximum number of positions to use in
search
(search = 50.) Translation search radius (arcsec)
(rsearch= 2.) Rotation search radius (deg) # Fine Centroiding
(cbox = 11) Centering box (pixels)
(maxshif= 10.) Maximum centering shift to accept
(arcsec)
(csig = 2.) Maximum centering uncertainty to accept
(arcsec)
(cfrac = 0.4) Minimum fraction of accepted centers
(listcoo= yes) List centered coordinates in verbose
mode? # WCS Fitting
(nfit = 4) Min for fit (>0) or max not found (<=0)
(rms = 2.) Maximum fit RMS to accept (arcsec)
(fitgeom= general) Fitting geometry
(reject = 3.) Fitting rejection limit (sigma)
(update = yes) Update coordinate systems?
(interac= no) Interactive?
(fit = no) Interactive fitting?
(graphic= stdgraph) Graphics device
(cursor = ) Graphics cursoraccept = yes Accept solution?
(mode = ql)
From: Frank Valdes <valdes@noao.edu>
Date: July 14, 2005 9:10:26 AM MST
To: Sam Schmidt <sschmidt@bruno.phyast.pitt.edu>
Subject: Re: IRAF (msccmatch) question
Hi Sam,I'm sorry for the delay in replying. I don't have an answer at this
point. My only comment is that the criteria for success can
sometimes be fooled and what looks like a solution is garbage. It
all depends on being able to tell if a centroid is a real star or
just blank sky. The key parameter there is "csig". Note that this
is related to the formal error of the centering and NOT how much the
center may be off due to astrometric reasons. So you should not set
it to something like 2. If the centroid is uncertain by up to 2
arcsec (assuming you have subarcsecond resolution) then that might be
achieved by random sky noise. You should set the parameter to
correspond to a small fraction of a pixel (say < 0.1 pixel). Then
only real brighter stars should satisfy this internal error measure.If you want to set me up with a specific example (the image, the
parameters, the
mscred and IRAF versions, and maybe the coordinate file) I would be
glad to see why it is off. To do this make a tar file and ftp it to
iraf.noao.edu/pub and let me know.Yours,
Frank
From: Sam Schmidt <sschmidt@bruno.phyast.pitt.edu>
Date: August 10, 2005 9:58:15 AM MST
To: Frank Valdes <valdes@noao.edu>
Cc: ahopkins@physics.usyd.edu.au, Sam Schmidt
<sschmidt@bruno.phyast.pitt.edu>
Subject: Re: IRAF (msccmatch) questionHello Frank,
Sorry I've waited so long to get back to you, but I was just back
from an observing run when I got this email and it got lost in the
shuffle. csig was, indeed, set to a high value given the pixel scale on
our images of 0.3165", but I changed this to 0.05 arcseconds and
msccmatch
still runs successfully and gives the same solution. I created a tar
file
with an example image, some parameter files, and a plot comparing the
ras
and decs to SDSS. You can grab the tar file at:http://www.phyast.pitt.edu/~sschmidt/FLAM/badastrom.tarThe verion of IRAF that I used is 2.12.2a-BetaLet me know if you need anything else, and if you have any other
ideas of
what I'm doing wrong.I've also cc'd Andrew Hopkins on this, as I believe he is still having
similar problems with another set of observations.Thanks,
Sam Schmidt
sschmidt@astro.phyast.pitt.eduFrom: Frank Valdes <valdes@noao.edu>
Date: August 16, 2005 12:22:17 PM MST
To: Sam Schmidt <sschmidt@bruno.phyast.pitt.edu>
Cc: ahopkins@physics.usyd.edu.au
Subject: Re: IRAF (msccmatch) question
Hi Sam and Andrew,I believe the difference is entirely due to the difference in
coordinates between
USNO:A2 and SDSS. My guess is the USNO:A2 is not as accurate because of
various reasons including the epoch difference and possible proper
motion
systematics. If I were you I would take the SDSS coordinates and use
them as
input to MSCCMATCH. From the vot.csv I would do the following:ms> fields vot.csv 2,3 > list1
ms> list = "list1"
ms> while (fscan (list, x, y) != EOF)
>>> printf ("%.2H %.1h\n", x, y, >> "list2")
ms> list = ""The file "list2" will have the RA and DEC in HMS and DMS format that
you can
use with the MSCRED tasks such MSCCMATCH.In general most small difference end up being due to the astrometric
catalog
differences and the trade-offs are usually depth and sky coverage vs
accuracy.
USNO:A2 is really the best astrometry catalog but it does have
coverage and
an easy interface with IRAF. Ultimately we would like to add USNO:B
and other
catalogs to the MSCGETCAT and AGETCAT tools. Stating the obvious, you
should be consistent in systems. So if you are going to be comparing
to data
calibrated against USNO then you should use USNO for MSCCMATCH. If you
are going to be comparing to SDSS then you should use SDSS catalogs for
calibration.I hope this helps.Yours,
FrankFrom: Sam Schmidt <sschmidt@bruno.phyast.pitt.edu>
Date: August 16, 2005 12:45:18 PM MST
To: Frank Valdes <valdes@noao.edu>
Cc: Sam Schmidt <sschmidt@bruno.phyast.pitt.edu>
Subject: Re: IRAF (msccmatch) questionOK, thanks, I'll try using the sdss coordinates. The file generated by
mscgetcatalog also has a set of magnitudes in addition to the ra and
dec,
are these used by msccmatch? Also, I'll let you know if this doesn't
fix
the problem.Thanks again,
Sam Schmidt
sschmidt@astro.phyast.pitt.eduFrom: Frank Valdes <valdes@noao.edu>
Date: August 16, 2005 12:46:52 PM MST
To: Sam Schmidt <sschmidt@bruno.phyast.pitt.edu>,
ahopkins@physics.usyd.edu.au
Subject: Re: IRAF (msccmatch) question
Hi Sam and Andrew,For my education I tried out the Open Sky Query thing you said you
used. I
compared SDSS and USNOB at your observation position and extracted the
RA/DEC values. I converted this to delta RA and delta DEC and
plotted it and
I got something very similar to the plot you sent. There is
definitely an offset
between these two catalogs.FrankFrom: Frank Valdes <valdes@noao.edu>
Date: August 16, 2005 12:50:03 PM MST
To: Sam Schmidt <sschmidt@bruno.phyast.pitt.edu>
Subject: Re: IRAF (msccmatch) question
The first magnitude is used to sort for the coarse registration. For
the fine registration
all the sources are used and the magnitudes don't matter. So you
might want to
use magnitudes or do the coarse registration (as was already done in
your example)
and then go back and just do the fine registration by setting the
search radius to
zero.Frank