iraf.net

I'm having a problem with getting ccxymatch to plate solve an image when extracting data from USNO A2.0 vs B1.0. I have A2.0 locally, but B2.0 I have to download via a small Perl script I wrote to use the CGI interface. The image is actually [b:6bb165554e]already[/b:6bb165554e] plate solved. What I'm trying to do is "fix" my script. However,Because the image has a plate solution, I can load it into ds9 and my shell script wrapper marks the stars found by sextractor using one color and those extracted from the catalog in another. I can see a moderate number of overlaps from either B1.0 or A2.0. But B2.0 gives a noticeably better set of overlaps with sextractor.I've got nmatch set to 50, I set the place scale to be very nearly correct (3 arc-sec/pixel when the solution is 3.1), and the RA and DEC for the place (from the nominal pointing) are good within an arc-minute. The object is NGC 7209, an open cluster. B1.0 includes stars in the cluster, A2.0 seems not to (or not much).The script pulls stars out from the catalog within one degree of the nominal pointing. My FOV is about 45'x30' so this is a bit more than the FOV, but not horribly excessive. The script then feeds different magnitude ranges into a reference file, then invokes ccxymatch. These images are specifically for pointing corrections (which I'm tryting to automate), and are not very deep; good S/N is really only down to mag 16. So the filter starts with stars from mag 9--13 and increase each limit by one after each failure. With B1.0, this very quickly gets a match. With A2.0, it never gets a match.Again, since I already have a plate solution, the script actually loads the image and markers from sextractor and the catalog extract into ds9 while it runs so I get visual feedback on how things are progression. It [b:6bb165554e]looks[/b:6bb165554e] like there ought to be enough stars matching for a solve, but ccxymatch fails repeatedly.Any tips on parameters to use? This uses nmatch=60, but I've tried 40, 50, and finally 60. All work when the extract is from B1.0; none when it is from A2.0. Here is the IRAF script invoked from my wrapper:

---

Roland B. Roberts, PhD RL Enterprises Brooklyn, NY

I'll start with a quick reply on the most obvious problem, if you still have problems please follow up.If you know the plate scale is 3.1 "/pix, why are you approximating it with just 3.0? On a 2K x 2K image this means you're off by 100" when moving from the center to the edge of the field, and even more out to the edge of the catalog. This kind of variable scale could well be why it isn't finding a solution.Another approach you can try is to use WCSCTRAN to convert your reference stars positions to image coords based on the current solution, then use XYXYMATCH to do the match in pixel space. You might also see the WCSFIXER web app from the NVO (http://iraf-nvo.noao.edu/wcsfixer), this is implemented as a set of IRAF scripts that does essentially what you're trying to do here. Hope this helps.Cheers,
-Mike

My initial solution was based on USNO B1.0 with an approximate plate scale of 3.0"/pixel, an unknown pointing error and rotation. It works fine.My attempted solution with 3.1"/pixel with my actually 2 arc-min pointing error fails. If I use xin, yin, lngref, and latref with the correct solution it finds it. On my 768x512 chip, the error due to the 3.0 vs 3.1 arc-sec/pixel at the edge is still small.The question is how can I, in the field when I do [b:99d864472e]not[/b:99d864472e] have access to B1.0 but only have A2.0, tweek ccxymatch to get a plate solution when I don't already have one. Typically my rotation is small; less than 5 degrees, but my pointing error can be significant, occasionally as high as 15 arc-minutes. Using B1.0 I still get a solution (although in my test case, the pointing error is less than 2 arc-min). Using A2.0 I can't when feeding in the same parameters.I I've fed this image into MaximDL on a Windows PC and used A2.0 for the reference catalog there with PinPoint and it gets a solution without any problem. That suggests to me it's a parameter problem, but I can't figure it out.I'll look at the tools you suggest and see about giving them a whirl. My aim is to be able to use catalogs on my local PC to to pointing corrections when in the field with no net access. In that case, I simply won't have a plate solution.

---

Roland B. Roberts, PhD RL Enterprises Brooklyn, NY