Reference stars returned

[Dustin Lang]

[An emailed question:]

> Is there a likely upper limit to the number of reference stars
> solve-field will use in generating its solution?
>
> I typically supply it with coordinates and flux for every in scene
> source in which more than 4 pixels are above 5 std devs above a
> flattened sky. In crowded fields that is often >500 stars so I whittle
> that down to 500 after sorting in flux - sum order.
>
> Is this overkill?
>
> Also, I have only ever found a few dozen reference stars within the
> .corr file. Is there a likely upper limit to how many it would be?

Hi,

For "blind" solves (the normal mode of operation) there is, in a roundabout way, a maximum number of reference stars.  The solver looks at sets of 3-4 stars in your image (depending on the index file), and searches for matching triangle/quadrangles in the index files.  It will only look at sets of stars that are larger than 10% of the image size.  And the number of reference stars in each index file is based on the (angular) size of the star features in that index file.  The index file tuned to solve images that are 1 degree wide has a lot more stars than the one tuned to solve images that are 4 degrees across.  So you're basically guaranteed to get something like 10-100 reference stars in your image.  (The theoretically possible range is probably larger than that, I haven't computed it exactly.)

So 500 stars is probably overkill :)  "--objs 100" would almost certainly do the trick.

Now, to get more matched stars, what you can do is run solve-field a second time, passing in the WCS file it found in the first round with "--verify IMAGE.wcs".  This will then search in all index files for the strongest match.

cheers,

dustin

[Grant Privett]

Thank you for your answer.

I had rather hoped I could cut back on the array length a bit. I will experiment with it.

For clarification though, if I used the  "-verify" option would that actually improve the plate solution or merely add more reference stars to the .corr file - which might be a very useful thing in its own right.

[Dustin Lang]

Both, it should increase the number of matched stars, which should improve the quality of the solution.

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/928c4a08-5054-4440-8c4d-11853518eec6n%40googlegroups.com.

[Grant Privett]

This is probably of limited interest to most users but I had a problem using -verify. Let me explain....

I am not using the whole image, but instead create a FITS bintable of 3 columns x ,y, flux(sum) with flux in descending order.

Then I run solve-field against that file and it creates a .wcs file that I extract the WCS from and add to the original image file. All hunky dory so far.

At that point .corr, .match, .rdls, .xyls, .solved and .axy files have also been created and are present..

If I then run (and yes, I know the file name is daft, but  the code is parallel and I'm running multiple instances simultaneously):

solve-field -verify tempfiletempfile_15948.wcs -v

I get a warning that an .axy file is already present and that I can use --overwrite or --continue to overcome it.

If I then try:

solve-field -verify tempfiletempfile.wcs -v --continue

It fails with a return value of 255 and a message that is:

Reading input file 1 of 1: "tempfiletempfile_15948.wcs"...
Base: "./tempfiletempfile_15948", basefile "tempfiletempfile_15948.wcs", basedir ".", suffix "wcs"
Checking if file "tempfiletempfile_15948.wcs" ext 0 is xylist or image: image
  (not xyls because: FITS file does not have any extensions)
Running: /usr/bin/python3 -m astrometry.util.image2pnm --infile tempfiletempfile_15948.wcs --uncompressed-outfile /tmp/tmp.uncompressed.rCvxKU --outfile /tmp/tmp.ppm.7G05Jj --ppm --mydir /usr/bin/solve-field
qfits: error: NAXIS = 0 in file tempfiletempfile_15948.wcs ext 0
an-fitstopnm.c:225:main: Failed to load pixels.
Command failed: an-fitstopnm -i tempfiletempfile_15948.wcs > /tmp/tmphk7krteo.pnm
augment-xylist.c:591:backtick Failed to run command: /usr/bin/python3 -m astrometry.util.image2pnm --infile tempfiletempfile_15948.wcs --uncompressed-outfile /tmp/tmp.uncompressed.rCvxKU --outfile /tmp/tmp.ppm.7G05Jj --ppm --mydir /usr/bin/solve-field
 ioutils.c:568:run_command_get_outputs Command failed: return value 255

Is it failing because the -verify option assumes the image was provided (image2pnm?) and not a bintable? 

Apologies if I am doing something really dumb.

[Dustin Lang]

Hi,

Two things:

- with long arguments, you need two dashes, so it's "--verify", not "-verify".

- when using --verify, you still need to provide the image/source list input argument.  The --verify just gives it the WCS, but what is it verifying?  It has to verify that the WCS correctly predicts the locations of stars in the image.

so you'll want something like

solve-field --verify tempfiletempfile_15948.wcs   tempfiletempfile_15948.axy

cheers,

dustin

To view this discussion on the web visit https://groups.google.com/d/msgid/astrometry/37b0c449-68e1-41a3-bff9-d4fe84f998b5n%40googlegroups.com.

[Grant Privett]

I added --width and --height too and it seems to run to completion with a status returned of 0. Just checking outputs now and whether the number of stars found or positional error estimate has changed.

[Alex Whittemore]

Well, sorry I've just come across this after already opening a github issue to ask a question this thread answers!

But I've got a new one: Your original paper describes that specifically quads are used, and while triplets and quints were tested, they were not used in the final product given the relative disadvantage to quads for the SDSS test set. I find this confusing because all the images I seem to solve end up with a triangle in "myimage-indx.png" to indicate the "quad" used to solve. 

>> The solver looks at sets of 3-4 stars in your image (depending on the index file), and searches for matching triangle/quadrangles in the index files.

I imagine this is to mean that the current version of the algorithm actually DOES implement using triangles instead of quads for certain scales, and my images all just happen to be wide enough to be in the "index made of triangles" regime? For instance, my images often solve with index 4112-4114. 

Thanks for everything,

Alex

[Dustin Lang]

Yes, exactly, triangles are used in the 4100-series index files for scales 11-19 (4111-4119).

cheers,

dustin

To view this discussion on the web visit https://groups.google.com/d/msgid/astrometry/1a5d6440-2ff4-457a-a01b-c4a37f5f5176n%40googlegroups.com.

[Alex Whittemore]

That seems to be also true for the 4200 indices at similar scale?

[Dustin Lang]

Looks that way.  You can find out by looking in the index file headers.

[Grant Privett]

*** SUCCESS ***

Okay, it went like this. I tried to use the --verify option in Astrometry.Net against a FITS bintable containing the x,y, flux values for a bunch of sources detected in wide angle (20 degs) imagery captured with an uncooled camera and a 24mm Canon camera lens.

The idea was that a refined AN solution would provide more reference stars in the .corr file which would make it easier for me to distinguish dim stars from potential movers, improve the error residuals on the polynomial used to cope with the lens/field distortions and, also, support an improved Zp estimation (I use only stars that are not of extreme colour nor contain any pixel that is above the point at which the sensor becomes non-linear in response).

Dustin suggested a couple of approaches we might take and, after several loops/iterations we established a way that worked simply and reliably. 

We probably would have iterated faster if there had not been a significant time zone difference and I had not had the mental agility of a stunned gerbil, due to a severe cold.   

 

TL:DR It works!

Looking at the results, I have increased the number of reference stars identified by ~80%, my median positional error has dropped and I have yet to test the Zp improvement - but the estimated error bars look very hopeful. So, a win, win, win!

First, undertake the usual plate-solve routine - in my case:

solve-field sourcesbintable.fit --tag-all --overwrite --no-plots --crpix-center --width 696 --height 520 --cpulimit 60 --tweak-order 2 --downsample 1 --scale-units degwidth --scale-low 0.1 --scale-high 180.0

followed after it has solved, by:

solve-field --verify sourcesbintable.wcs sourcesbintable.fit --width 696 --height 520 --tag-all --continue 

 

On the small image I gave it, the extra run time was less than 1s  on a 2.8GHz laptop and, as I was running it via a Windows WSL session, theres also a Ubuntu session startup time to be factored in. 

Remember though this is for running using a FITS binary table of detection info. If you are instead running against a normal 2D image, its much easier and less fiddly.  My usage is a little niche.

Thanks to Dustin for his patience (again).

[Grant Privett]

A follow on question occurred to me ....

If --verify looks at Index files of higher resolution than our input image to find additional reference stars and improve the solution, does astrometry.net look just at the the next Index set down or does it go further than that?

Just ran it against some data and --verify doubled the number of stars used in the plate solution, which is impressive.

[Dustin Lang]

It looks at all of them :)

To view this discussion on the web visit https://groups.google.com/d/msgid/astrometry/cf7a6afe-1f50-4956-9805-2939e4755bb2n%40googlegroups.com.