Using the online solver also gives 144º:



Using the online solver also loops forever. Log attached.

> How do I plate solve in Siril?
Go to "Hamburger Menu" (upper left corner) / Image Information / Image Plate Solver ... .
Just solve with uncorrected and unstretched (so called linear) image.

> Here is the solve in ASTAP giving a rotation of 144º
OK. that's it. We have a pretty confusion in rotation senses. Interactive 'Astrometry' returns -144° as does 'Internal SEP' & 'Local/Online Astrometry'. "Builtin Method for Solver" & 'Local/Online Astrometry' gives still another angle (324° = 180° + 144°).
All problems are a consequence of this problem! Strange that until now nobody stumbled upon this.

@alacant: Just try 'Internal SEP' & 'Online Astrometry'. Wondering what happens!
@Jasem: How and where should we take care of the different interpretations of rotation angles?

OK. As soon as I can, I shall...
Please could we have it work with ASTAP? It seems by far the quickest and most reliable.
Cheers and TIA for all your time,
Steve

Solved in Siril. Agrees with 144º too:

Catalog TYCHO-2 size: 696 objects
00:24:11: 223 pair matches.
00:24:11: Inliers: 0.717
00:24:11: Resolution: 1.195 arcsec/px
00:24:11: Rotation: +144.32 deg (flipped)
00:24:11: Focal: 649.09 mm
00:24:11: Pixel size: 3.76 µm
00:24:11: Field of view: 02d 03m 56.64s x 01d 23m 0.06s
00:24:11: Image center: alpha: 20h15m27s, delta: +41°33'39"

**still trying the online solver. It's taking ages...

Finally got it uploaded and solved.
Using Internal SEP and Online Astrometry gives 35º, so not in agreement.
Any help?



Cheers and thanks once again for your time.

... and just for good measure, here is a local copy of astometry.net (@Toni I think this is what you used initially) getting the orientation correct and then -correctly stopping when it had both the RA/DEC and the PA correct, BUT reporting an angle of +35º:

Observation using latest Siril alpha from git:
The solve first flips flips the image then solves to give the infamous -35.73º. Call it -36º
Then 180 -36 = 144º

04:12:37: Plate solving image from an online catalogue for a field of view of 2.48 degrees, using a limit magnitude of 12.32
04:12:37: Catalog TYCHO-2 size: 688 objects
04:12:37: Findstar: processing for channel 1...
04:12:38: Using 688 detected stars from image.
04:12:38: Up is -35.73 deg ClockWise wrt. N (flipped)
04:12:38: Resolution: 1.195 arcsec/px
04:12:38: Focal length: 648.84 mm
04:12:38: Pixel size: 3.76 µm
04:12:38: Field of view: 02d 03m 59.50s x 01d 23m 1.98s
04:12:38: Saved focal length 648.84 and pixel size 3.76 as default values
04:12:38: Image center: alpha: 20h15m27s, delta: +41°33'39"
04:12:38: Flipping image and updating astrometry data.

So some solvers give -36º, others give 144º
Would it be possible to standardise the rotation angle so that all methods agreed upon the orientation?
Probably easier said than done...

Cheers

@alacant: Thanks for your effort and detailed information. Your are so right to demand a correct handling of the rotation angle in a solver for astronomic pictures! The discussions in this field are old and multifaceted. Fortunately the definition for the position angle (PA) is clear:
"The International Astronomical Union defines it as the angle measured relative to the north celestial pole (NCP), turning positive into the direction of the right ascension. (Wikipedia)"
Sometimes this is - not really correct - abbreviated to "N to E".

Various inquiries about rotation in astronomy pictures bring some light to the situation. In conjunction with our problem, there are essentially two parameters which have a main impact in calculating the rotation: Parity and RowOrder of a fits file. (I'll try to clarify more in an other post.)

My summary so far concerning alacant's image with correct PA = +35.7°:

• Interactive solver nova.astrometry.net returns correct rotation of -144.3°. Because the fits image has Parity=neg and KStars produces fits with RowOrder=Top-Down the image has to be rotated by 180°. So the PA is -144.3° + 180° = 35.7° which is correct.
  
• "Old Siril" returns the wrong rotation of 144.3°. 'RowOrder' is not handled. (see here )
• Latest Siril returns the correct rotation of -35.7° clockwise wrt N, which equals to PA of 35.7°. 'RowOrder' is handled. (see here )
• Internal SEP & Local/Online Astrometry returns the correct rotation of -144.3°, which gives the correct PA of +35.7°. 'Parity' and 'RowOrder' are interpreted correctly.
• Builtin Method for Solver & Online Astrometry returns a wrong rotation of 324°, which gives the wrong PA of 144.3°. I don't know what happens.
• Builtin Method for Solver & Local Astrometry returns the correct rotation of -144.3°, which gives the correct PA of +35.7°. I don't know what happens, but it seems 'Parity' and 'RowOrder' are interpreted correctly.
• Builtin Method for Solver & Local Astap for alacant returns a wrong rotation of 144.3°, which gives the wrong PA of -35.7°. I suppose 'RowOrder' is not handled. (see "Old Siril")

Three questions are emerging:

1. What is the exact meaning of "Builtin Methods for Solver" in EKOS?
2. Is it correct, that ASTAP does not handle 'RowOrder'? (@alacant: What's your version?)
3. What about the third option (Local Watney) in EKOS?

Builtin Methods for Solver means use whatever is default in the solver. So for Local Astrometry, use the SEP that already comes with astrometry.net and so on.

[Jasem Mutlaq post=94021] Builtin Methods for Solver means use whatever is default in the solver. So for Local Astrometry, use the SEP that already comes with astrometry.net and so on.
How come the built in methods of local and online astrometry return different results?

Hi Toni, everyone

Other than volunteer to test any MRs, I'm afraid I can't help with parity and row order stuff as I don't know what they are.

What I do know is that ASTAP with it's built in method does not work; it loops without ever settling on a rotation.

Would it be possible to fix the code so that it gets the rotation correct?

Actually, all I want is that after I solve an image from my actual camera, the rectangle is correctly oriented on Kstars to help me frame. Is that what is supposed to happen?
If we could also make the simulator rotate consistently, that would help take away the guesswork when planning a session.

Thanks

Quick question - clear night ahead:

For now, what (non online) combination of source extraction + solver DOES give me the correct orientation rectangle on Kstars when I take a photo with an actual camera?

Here for example is the processed image with two alternatives:
builtin/astap
builtin/local astrometry

Cheers