Not polynomial order expected

[Grant Privett]

Hi there,

I'm plate solving some frames for use in Tycho-Tracker - which likes a tweak polynomial of 3 - and finding that despite my script specifying a tweak value of 3 I always get 2nd order polynomial fits.

An example of the instruction I use is:

solve-field /mnt/c/data/obj-20240322-1/tempfiletempfile.fit --tag-all --overwrite --no-plots --crpix-center --cpulimit 30 --tweak-order 3 --downsample 2 --ra 177.499 --dec -0.728 --radius 0.378 --width 2734 --height 2184 --no-remove-lines --uniformize 0

The ra and dec values provided are from the previous solved frame. 38 stars are used.

Any thoughts very welcome.

Thanks.

[Dustin Lang]

Hi Grant,

(Sorry that the spam filter flagged your messages!)

That command looks fine to me.  I would have expected 38 stars to be okay for a 3rd-order polynomial.  It looks like the code would want >= 10 stars:

  https://github.com/dstndstn/astrometry.net/blob/main/util/fit-wcs.c#L112

but those are "correspondences", ie, stars that we think matched... so maybe you're getting fewer than that number lining up well enough to be considered matches from the initial solve.  It should print that error message about too few correspondences if that's what's happening - and it should tell you how many that is.

You *could* try a two-stage solve -- do an initial solve-field without 'tweak', and then run a second time, passing the first-round WCS file with "--verify FILE.wcs" ... that will end up trying your solved image against all index files, sometimes using a denser index that may result in more correspondences.

cheers,

dustin

--
You received this message because you are subscribed to the Google Groups "astrometry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astrometry+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/astrometry/f263d22b-5b7d-48bc-9f0a-7c3cd8e0d79en%40googlegroups.com.

[Grant Privett]

I will give that a go and report back on what happens. 

I'm working with data thats near saturated (probably dumb to do photometry on stars when the moon is close) and the dynamic range is small, so I can cope with it taking an extra second or two per frame if  need be. Otherwise whats the point of all those idling cores...  

[Grant Privett]

I have now tested my code against 200-300 frames taken on 3 different nights with the Moon between 7 and 15 degrees away from the boresite.

I have done what Dustin suggested i.e. solved the image with whatever information I had to hand (field size, RA, Dec etc) using tweak=2 and then called it again using the -verify option and including "--tweak-order 3".

I've manually looked at frames from 20 pointing and they each have a polynomial order set to 3rd. Theres been no obvious slow down (or speed up) because of it, which is great.

So thanks, as always, to Dustin for his sound advice.

Tycho Tracker is now happily chewing its way through my datasets...

Grant