issue with images on the edges of healpix tiles; margin around tiles not working as expected?

[pmvreeswijk]

Hi,

First I'd like to mention that it's a pleasure to use Astrometry.net for our imaging survey (MeerLICHT); for most of our fields the astrometry is excellent (~0.03" standard deviation when compared to Gaia DR2 sources in the field), using scales 4-6 for our 100'x100' images. We are using Astrometry.net version 0.78.

However, for a number of our fields, the astrometric solution is much worse than expected (factor ~10) for no apparent reason (image quality is fine). We find that these fields are actually located on the edge of a healpix tile. And when plotting the index sources returned by solve-field in the .xyls file, a large fraction of the field is missing index sources, as if sources across the healpix tile border are not being used - see the plot below. This is the case for both the index 5000- and 5200-series that are provided here, and also for the index files that we created ourselves (following these useful notes), using nside=1 or 2 and sources with low proper motion from Gaia DR2. The plot below is for a field centered at RA,DEC=92.4077,-38.9261 degrees, solved (poorly) with index-5206-37; our CCD has 10.5k x 10.5k pixels.

When using full-sky index files, the sources in .xyls are spread across the entire image (same for the 4100-series) and the astrometric solution is excellent again. The problem can also be solved while using the healpix tile split, but only when adding the -m(argin) option in both the hpslit (in our case: -m 1) and build-astrometry-index (in our case -m 5) commands. Just using the hpsplit margin option is not enough, while the build-astrometry-index margin option appears to be considered unimportant in the index-building notes.

So it's straightforward to solve this, but wanted to let you know about it just in case you're not aware of it already.

Best regards,
Paul

[dstndstn]

That's interesting. That RA,Dec is actually inside healpix 20, not healpix 37, but it is about 0.6 degrees away from the boundary. So it looks to me like it did solve in an index with a margin.

The way it's supposed to work is:

• hpsplit splits stars into healpixes, but keeps ones near the margin
• bulid-astrometry-index only tries to create micro-constellations centered within its healpix

This way, there are always stars available to "verify" a match, even if the matched micro-constellation is at the edge of the healpix.

Oh, but maybe the margins I'm using are too small for the larger scales like yours.

[pmvreeswijk]

Dear Dustin, Thanks for your quick response.

That's interesting. That RA,Dec is actually inside healpix 20, not healpix 37, but it is about 0.6 degrees away from the boundary.

Inside healpix 20 indeed, but much closer than 0.6 deg to the boundary with healpix 38, no? More like 0.1. Actually, I’m rather puzzled why the solution indicates healpix 37 instead of 38 (or 20).

So it looks to me like it did solve in an index with a margin.

Ok, but what I don’t understand is why half the field is missing index sources as listed in the .xyls output file. And the solution it finds is rather poor; I suspect that if I would use the full-sky/non-tiled index files for the 5200 series, the solution would be much better. Actually, would it be possible for you to also provide those full-sky index files for the LIGHT version of the 5200 series for the larger scales: 4-6? cheers, Paul

[dstndstn]

The solution was found using a micro-constellation within healpix 37. That index contains some margin stars, but not enough to cover your whole image. (Because -m 1 means a 1-degree margin). And because it only has stars in half the image, the solution is relatively poor.

One solution would be to produce new versions of these index files, with larger margins for the larger scales. Or, as you say, produce all-sky files.

[serenaalmy]

Hi Paul,

Thank you so much for posting this. We (my professor and I) have many images of one field that we've been trying to stack. The plate solutions have not been the most accurate due to this heal pix boundary issue (it turns out).