WCSAXES keyword placement

[Robert Siverd]

Hi,

I recently noticed that the WCSAXES keyword is ~illegally placed in FITS headers from astrometry.net (using solve-field / new-wcs command line tools). When present, apparently WCSAXES must precede all other WCS keywords (in my case it appears after CTYPE1/CTYPE2). I wonder if (a) this is a known issue and (b) if there's a pending update that might fix it. I'm currently running v0.25, but later revisions (I tried 0.42) still have the same placement.

For reasons unrelated to astrometry/WCS, I examined a few images with fitsverify. To my surprise and chagrin, this is considered an error in the FITS file. Digging around, I found the "must come first" requirement in Greisen and Calabretta (2002), section 2.2 (page 1066).  This isn't a problem for me (I've been using astrometry.net for years and only noticed this issue two days ago) but others might find it problematic. Fortunately, it should be easy to fix.

For completeness, note that fitsverify also whined about the presence of two DATE keywords (new-wcs didn't erase the DATE already present), but this only generates a warning and only affects images that already have DATE in the header. For reference, here's an online list of FITS error/warning conditions from NASA/HEADAS/ftverify:
http://heasarc.gsfc.nasa.gov/ftools/caldb/help/ftverify.html

I've attached the fitsverify output for reference. I hope this helps! Thanks for your continued work on this extremely useful software.

Cheers,
Rob Siverd

[Dustin Lang]

Thanks for your note!

It turns out this check for WCSAXES was only added to fitsverify in version 4.16, but I had v 4.13 so I didn't see that this is now considered a bug.

I put in a fix in new-wcs.  This will appear in the next Astrometry.net code release (coming very soon, since I found another important bug today also).

cheers,
dustin

[Robert Siverd]

Great, thanks very much for the quick response!  I'll keep my eyes open for the next version.

-Rob

[Dustin Lang]

 This fix appears in the 0.43 release, and the nova web service is also updated.  Any testing you can do would be appreciated.  Fitsverify says the wcs.fits files we produce are ok, but it is still possible for the new-wcs program to produce bad headers if the input header is bad.

[Robert Siverd]

I've done some testing and have a few comments and questions.  In case it helps, my images are 4K x 4K @ 23 arcsec/pix (26 x 26 deg).  I find stars with SExtractor, manually scrub spuriae from the catalog, and feed the result to solve-field. I get nice results with 5th-order polynomial tweaks.

Sucesses first:
1) v0.43 built without issue (CentOS 6 x86_64) and seems to mostly work
2) FITS files produced with new-wcs have WCSAXES first and no longer incur the wrath of fitsverify
3) My old astrometry.net install (v0.25) finds solutions with the 4100-series files (though solve-field whines about file format on stderr).  New indexes are presently ~10% slower than old (using v0.25), but this could *easily* be due to including too many.
4) The new version (v0.43) solves my test case using old indexes without issue.

Unexpected:
4b) Although old indexes (213 & 214) solve and tweak, it takes ~3x longer in v0.43 than in v0.25 (16s vs. 6s). This may be normal if the old-style quad listings are not ideal for the new search engine.  The log file is also 10x or 20x larger than other search cases in this instance.

Not working:
5) The new version of solve-field (v0.43) refuses to tweak the solution. The raw solution is close, but the WCS becomes significantly incorrect away from the reference point without the polynomial distortion fix. solve-field says "No matches -- aborting tweak attempt" and stops looking after ~0.05 sec (I've got a 30-sec CPU limit).

I may be doing something wrong on my end but this seems pretty weird.  I've attached log files with the output of solve-field for the 4 different combinations (v0.25 & v0.43 with old vs. new indexes).  I really appreciate any advice you can provide.

Thanks,
Rob

[Robert Siverd]

*bump*

These are the issues I found with 0.42:

-- v0.42 takes 3x longer than v0.25 to solve the same images using the same (old) indices.

-- v0.42 refuses to do polynomial tweaks when using new (Tycho-2) indices using exactly the same options as above.

In the latter case, solve-field aborts after 0.05 sec (despite 30sec CPU limit) with "No matches -- aborting tweak attempt".

In summary, v0.42 was either significantly slower or completely unusable with images I tested compared to the older v0.25. I'm not sure what changed or how to fix it.

-Rob

[Dustin Lang]

Hi,

The performance changes you report between 0.25 and 0.42 are very surprising to me.  Could you please send a test image, and tell me which index files you are using.

Could you please send the log file for the v0.42 failure to do a polynomial tweak.

thanks,
--dustin

[Robert Siverd]

Hi Dustin,

I tried both astrometry versions (0.25 and 0.43) with two sets of indices. The FOV is 26x26 deg.

The "old" indices are: index-213.fits   index-214.fits

The "new" indices are: index-4115.fits  index-4116.fits  index-4117.fits  index-4118.fits

This is the log for tweak failure using v0.43 astrometry and "new" (4100-series) indices:

http://astro.phy.vanderbilt.edu/~siverdrj/WCS/test_data/log.043.newdex.txt

This is the log for slow tweak success using v0.43 astrometry and "old" (200-series) indices:

http://astro.phy.vanderbilt.edu/~siverdrj/WCS/test_data/log.043.olddex.txt

Logs for faster/working solutions using v0.25 and old/new indices respectively are:

http://astro.phy.vanderbilt.edu/~siverdrj/WCS/test_data/log.025.olddex.txt

http://astro.phy.vanderbilt.edu/~siverdrj/WCS/test_data/log.025.newdex.txt

I've gathered everything you should need in here:

http://astro.phy.vanderbilt.edu/~siverdrj/WCS/test_data/

Data files are:

qcal.fits -- the target FITS image (dark-subtracted and flat-fielded)

Zcatalog.txt -- Source list from SExtractor.

Zcatalog.fits -- SExtractor source list in FITS format. Created with xylist2fits -x XWIN_IMAGE -y YWIN_IMAGE Zcatalog.txt Zcatalog.fits

The solve commands I used are (identical except for index selection in backend):

time solve-field -b backend.olddex.cfg -v -2yOp  Zcatalog.fits --x-column XWIN_IMAGE --y-column YWIN_IMAGE -l 30 -t 5 -c 0.0005 -L 20 -H 25 -u arcsecperpix -D temp -q 0.05 --width 4080 --height 4080

time solve-field -b backend.newdex.cfg -v -2yOp  Zcatalog.fits --x-column XWIN_IMAGE --y-column YWIN_IMAGE -l 30 -t 5 -c 0.0005 -L 20 -H 25 -u arcsecperpix -D temp -q 0.05 --width 4080 --height 4080

-Rob

[Dustin Lang]

Hi,

I would suggest that you try an apples-to-apples test.

The last two digits of the index filename tells you the "scale" of the features in the index; index files 213 and 4113 each contain features with diameters 170 to 240 arcminutes.  The "old" and "new" index files you list below have non-overlapping scales, so I'm not surprised they perform differently!

I would suggest grabbing index-4113 and index-4114 and either add them to your other 41* files, or test just those two vs the "old" set.

About the tweak failure: it looks like it might be locking onto a wrong solution -- it starts with a good solution (high logodds) but then during the "annealing" it goes haywire.

Thanks for sending those example files -- that should help to figure out what is going wrong.

cheers,
dustin

[Robert Siverd]

Hi Dustin,

Thanks for looking into this.

On Tuesday, June 25, 2013 1:32:55 PM UTC-5, Dustin Lang wrote:

I would suggest that you try an apples-to-apples test.

The last two digits of the index filename tells you the "scale" of the features in the index; index files 213 and 4113 each contain features with diameters 170 to 240 arcminutes.  The "old" and "new" index files you list below have non-overlapping scales, so I'm not surprised they perform differently!

You're absolutely right about the different indices and speed comparisons. What I meant (but failed) to convey is that I find significant differences between v0.25 and v0.43 in two different apples-to-apples comparisons. Specifically I found that:

1) Using exclusively 200-series indices, both v0.25 and v0.43 work but v0.43 takes almost 3x longer to solve.

2) Using exclusively 4100-series indices, v0.25 works fine but v0.43 fails at the tweaking stage.

In other words the speed difference is exclusive to 200-series indices and the works/fails issue is exclusive to 4100-series indices. Lastly, I note (unfairly) that v0.25 is ~equally speedy with my peculiar choice of 200-series and 4100-series indices. Changing index files could certainly change this.

About the tweak failure: it looks like it might be locking onto a wrong solution -- it starts with a good solution (high logodds) but then during the "annealing" it goes haywire.

Thanks for sending those example files -- that should help to figure out what is going wrong.

Let me know if you need anything else to track this down. I would like to upgrade for the new features but need the distortion tweaks to work first.

-Rob

[Robert Siverd]

Any news on this issue? I did some further testing and found the same problem whether I use SExtractor or built-in source identification. Other than that, I've got nothing to add unfortunately.

-Rob

[Robert Siverd]

I have an update ... I can make the polynomial tweaker run under certain circumstances. Whether or not the tweaker runs or gives up depends on a combination of command-line options and  choice of index files (using 4000-series). Hopefully the option/index combos shed light on this (I'm completely baffled).

The command I've tried is:
solve-field -v -b backend.newdex.cfg -D tmp_043 -L 20 -H 25 -u arcsecperpix --no-plots --overwrite --no-verify --tweak-order 5 --downsample 4

Using the command above, the solver quits without tweaking ("No matches -- aborting tweak attempt") when using only a combination of these indices:
index index-4119.fits
index index-4115.fits
index index-4114.fits
index index-4113.fits

The "No matches -- aborting tweak attempt" error can be avoided by including other index files. With the same command+options above, the tweaker works if I include one of these three indices: index-4116.fits, index-4117.fits, index-4118.fits.  I have no idea why this is.

Completely separately, this tweak-abort error can be avoided by (unrelated) command line options. Using only index-4113.fits and index-4114.fits, for instance, the tweaker works when I specify either "--objs 500" (reduces object list size) or "--crpix-center". These options don't seem related and it's not clear why they independently fix the "aborting tweak attempt" issue.

Hopefully these data points provide some additional insight. I'm at a loss.

-Rob

[Abhishek kumar]

very useful information. thanks a lot for this.

thanks

99thin