StellarSolver and Parity (and ASTAP)

[Robert Lancaster]

Hi Hy,

I didn’t get the parity from ASTAP because I didn’t believe it reported that information.  It isn’t in the INI file.  However, I just took a look at the astrometry.net <http://astrometry.net/> wcs calculations and I think we may be able to calculate the parity from the INI file ASTAP produces.

If I am reading this correctly, we can do the following:

cd11 * cd22 - cd12 * cd21

And if that produces a positive number, it is positive parity, but if it is negative, it is negative parity.

Please let me know if this sounds correct.  I can always add this to StellarSolver if it is correct.

Source:
https://github.com/dstndstn/astrometry.net/blob/main/net/wcs.py

As for the Local solver getting the parity wrong, the code I am using in StellarSolver to read the WCS file is the same code we were using to read the solution files before in KStars.  I basically just moved it.  It reads the “parity”  key-value pair.  I can check into this to see if something was missed.  In fact, if you think the above calculation would work, I could just do that for the local solver as well.

Rob


> On Apr 6, 2021, at 9:33 PM, Hy Murveit <murveit at gmail.com> wrote:
> 
> Background: 
> Jasem and I have been working on an issue related to solving and polar alignment. It turns out that the KStars WCS code has been ignoring what astrometry.net <http://astrometry.net/> calls "parity", and that causes methods like FITSData::wcsToPixel or pixelToWCS to give wrong answers for off-center pixels when the image has positive parity (which tends to happen e.g. for RASA telescopes (reflectors at prime focus). Most setups have negative parity, which is why we haven't seen tons of complaints before.
> 
> Solution:
> There's likely a very simple fix--negating the FITS header keyword CDELT1 when the parity is positive, but we need to know the parity of the solved image. StellarSolver's Solution struct contains a (QString) parity field.
> 
> However...
> 
> I just checked with a fits image of mine (which is negative parity) and tried the 4 possible StellarSolver solving options (both in KStars and StellarSolverTester) and all methods solved the image, and the parity field was filled as follows:
> Internal Solver returned  (negative) parity
> Local ASTAP did not return any parity
> Local Astrometry returned (negative) parity
> Online Astrometry returned (negative) parity.
> Then, I flipped that image (using FastRotation-->Horizontal Mirror in PixInsight, saving to a .fits). The image should now solve with the same coordinates but have positive parity. Running the same test I found:
> Internal Solver returned  (positive) parity
> Local ASTAP failed to solve the image.
> Local Astrometry returned (negative) parity
> Online Astrometry returned (positive) parity.
> The bold lines above indicate issues. Basically:
> Local ASTAP seems to fail on positive parity images (on an image it quickly solved with the other parity), and does not return parity for the negative parity images it does solve (all via StellarSolver--I didn't try ASTAP natively). Perhaps StellarSolver is setting some wrong command-line flag?
> Local Astrometry did not return the right parity for positive parity images. Does it always return negative (all via StellarSolver--I didn't try it natively).
> Rob, Han, any suggestions/comments? Is there a configuration I'm missing?
> 
> Thanks,
> Hy
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20210406/61afae2b/attachment.htm>