Astrometry _before_ characterising

For reasons too boring to go into here, the camera I’m developing an obs_package for doesn’t give accurate wcs information in the headers of the raw images (I’m talking tens of degrees out). I wanted, however, to make use of the reference source matching option when characterising the PSF in, which requires accurate astrometry. I may have been mistaken, but the only way I could see of doing this was to solve astrometry after ISR but before characterizeImage, so I’ve written my own astrometry task (that uses meas_extensions_astrometryNet) which gets called from between ISR and charImage. I’ve not robustly tested it yet, but it’s working blindly without pointing (RA,Dec), but with a crude plate scale.

If anyone else thinks they may find this useful for their own cameras, or if (in the unlikely event that) someone would like to incorporate my hack into the stack proper, then please reply to this thread (I didn’t want to start forking then pushing without prior warning).

Finally, while working with meas_extensions_astrometryNet, I noticed a couple of things (v15 of the stack running on Debian Linux64):
o aNetL227:
Here, self.distortionContext was throwing a ‘does not exist’ error, so I had to comment it out and remove bbox from the following line.
o ANetL440:
Here, it seems that wcs no longer has a hasDistortion() key, so I had to remove it from the comment. (I searched the whole organisation and couldn’t find any other reference to hasDistortion).

For special cases like this the idea would generally be to create a subclass of CharacterizeImageTask that basically is just a shell wrapping the run method. In there you could insert the astrometry code (and any relevant config options you may need). Then when configuring the processCcd task you could just retarget the charImage task to your custom task.

Your solution certainly will work, I only bring this up as a general design discussion in case you find it useful to consider in the future.


Thanks for pointing that out. I did suspect that what I’d done may have been a bit of a brute force method and there’d be a more elegant way to achieve it. I’ll have a go at doing what you suggest, while falling back on my current approach in the meantime.

Just to close this up. I’ve done as @natelust suggested and it’s working well. I now know how to make changes specific to our needs without hacking the stack proper - useful knowledge.

Should anyone come across this thread in the future and wish to take a look at my solution, my obs_package is available at obs_goto (current commit: 0a59efd), with relevant code in:

  • config/
  • python/lsst/obs/goto/
  • python/lsst/obs/goto/

Thanks again.