StellarSolver and Parity (and ASTAP)

[Robert Lancaster]

Hi Hy,

Yes, I think he is in this email group,  I just checked and there are several exchanges between him and you in this group, so my guess is yes. If not, you should have his email address in your email history.  If not, I can send it to you.

For ASTAP, I wouldn’t think that the issue would be a command line flag since it wouldn’t know the parity prior to solving.  So I should think it would solve both ways. But if I need to add a flag or two for StellarSolver’s use of ASTAP, I can.

I can add the code and see if at least it says the right parity when it does solve.

Rob

> On Apr 6, 2021, at 10:39 PM, Hy Murveit <murveit at gmail.com> wrote:
> 
> Thanks Rob,
> 
> Probably right, but easy to verify since you already have a working solution. Also, for another check, the parity is in the wcs.fits file that one can download from the online astrometry.net <http://astrometry.net/>.
> 
> I am concerned that ASTAP didn't solve my positive parity image (which as I mentioned was the exact-same-but-mirrored image it solved as negative parity), but I assume/hope that it is a user-issue (e.g. some command line flag or the like is off). I don't have Han's email, and don't know if he reads this mailing list. Could you please forward these questions to him?
> 
> Thanks,
> Hy
> 
> On Tue, Apr 6, 2021 at 7:30 PM Robert Lancaster <rlancaste at gmail.com <mailto:rlancaste at gmail.com>> wrote:
> Sorry one correction to my last email.
> 
> I just checked the internal stellarsolver parity code, there is this comment:
> 
> // Note, negative determinant = positive parity.
> 
> So that means if this 
> 
>> cd11 * cd22 - cd12 * cd21
> 
> Produces a negative number, that is a positive parity and vice versa.
> 
> Sorry for the mistake in this last email.
> 
>> On Apr 6, 2021, at 10:27 PM, Robert Lancaster <rlancaste at gmail.com <mailto:rlancaste at gmail.com>> wrote:
>> 
>> 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 <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 <mailto: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/20210407/18750d42/attachment.htm>