Astrometry.net and SWarp

[Curtis McCully]

I am interested in using astrometry.net in conjunction with swarp to do image subtractions to search for supernovae. However, it appears that SWarp does not understand the TAN-SIP projection. Is there a way around this issue? Am I missing something? Thanks.

[Dustin Lang]

Good question.  I think Scamp/Swarp use the "PV" convention to represent polynomials, while we use the (now more popular, I think) SIP convention.  One option is to use SCamp before SWarp -- in principle that should give you better alignments anyway, since SCamp can use all the sources detected in all your images.  And SWarp will understand SCamp's outputs.  The solve-field program can produce outputs that SCamp understands -- see the solve-field --scamp option (and --scamp-config and --scamp-ref).

Another option would be to write a program that evaluates our SIP solution on a grid and computes an equivalent PV WCS header.  I have done the opposite in the wcs-pv2sip.c code, not that that helps you much...

cheers,
dustin

[Curtis McCully]

Thanks for your quick response. Do you happen to know of a reference for the SIP to PV transformation (I found a reference for the opposite transformation)?

[Dustin Lang]

Do you mean an analytic transformation?  No, I don't know of such a thing -- but that doesn't mean it doesn't exist!  In my wcs-pv2sip code I just do it numerically -- evaluate the PV transformation on a grid of points, and solve the least-squares problem for the SIP coefficients.  The same approach would work for the other direction.  But an analytic one would be better, since it would both be cheaper and preserve the information.

It may be impossible to write both directions analytically -- the PV transformation includes some terms that are not straight polynomials in x and y; from my notes,

xi =   PV1_0                      
     + PV1_1 * x                  
     + PV1_2 * y                  
     + PV1_3 * sqrt(x**2 + y**2)  
     + PV1_4 * x**2               
     + PV1_5 * x*y                
     + PV1_6 * y**2               
     + PV1_7 * x**3               
     + PV1_8 * x**2 * y           
     + PV1_9 * x * y**2           
     + PV1_10* y**3               
eta =  PV2_0                      
     + PV2_1 * y                  
     + PV2_2 * x                  
     + PV2_3 * sqrt(x**2 + y**2)  
     + PV2_4 * y**2               
     + PV2_5 * y*x                
     + PV2_6 * x**2               
     + PV2_7 * y**3               
     + PV2_8 * y**2 * x           
     + PV2_9 * y * x**2           
     + PV2_10* x**3               

Those SQRT terms are going to pose a problem...

--dstn

[Curtis McCully]

I have been looking at the following paper as a reference for this problem. It includes higher order terms than your notes, but is otherwise identical. http://web.ipac.caltech.edu/staff/fmasci/home/astro_refs/SIP_To_PV_2012.pdf

I think you may be right that it is not analytically solvable with the square root, but I think we might be able to get around that. I think if you set all of the PV terms that multiply that square root to 0, the PV coefficients basically become the SIP coefficients (within a factor of the CD matrix) and should just be algebraically solvable going from SIP to PV. Going the other way is more of a problem if the PV_1_3 is not zero in which case you are correct that you likely need to solve for the transformation numerically.  Perhaps one solution would be to keep the WCS as it is in the header, but also calculate the PV keywords and include them in the header. I believe that SExtractor and SWarp both check if the PV keywords exist before they check the CTYPE keywords. As such, we could have it such that the astromatic software has a transformation it recognizes, but the WCS solution is still in the SIP convention for everything else, like DS9. Does a solution like that sound sensible?

[Dustin Lang]

I don't think putting both SIP and PV distortions is a good idea.

FITS WCS headers are supposed to be understandable by looking at the CTYPE# headers.  If you want TAN + PV, you should use TPV; for TAN + SIP it should be TAN-SIP.

As for the idea of fitting for TPV instead of SIP -- that is certainly possible, but honestly not very high on my personal wish list.  It's an open-source project, so if you're interested in trying to add that code, it would be welcome.  The place to look is blind/tweak.c in the function do_sip_tweak().  Note how it builds a least-squares problem using the SIP polynomial terms.  The major difference is that (as I understand it) the PV terms operate on intermediate WORLD coordinates (ie, RA,Dec space), while SIP operates on intermediate IMAGE coordinates.

I suspect it would be easier to write a stand-alone wcs-sip2pv converter, though.

By the way, TPV and SIP are both "registered conventions"; neither are part of the FITS "standard".

http://fits.gsfc.nasa.gov/registry/tpvwcs.html
http://fits.gsfc.nasa.gov/registry/sip.html

[Curtis McCully]

Ah. I had not appreciated the difference in when the transformation is applied for each case. I wasn't actually thinking of fitting in terms of TPV, but due to a misunderstanding I thought you could directly translate the two coordinates.

I think it looks like it would almost be easier to add SIP to SWarp, though it would take a few hacks. Thanks for your help with this.

Curtis