Hi Alacant, if I understand it correctly, this is what Toni addressed in message indilib.org/forum/ekos/13546-alignment-w...on-kstars.html#94019

SEP/local astrometry fior example gives the correct result.

"SEP/local astrometry fior example gives the correct result."

Hi and thanks for your post.
Unfortunately, it seems not.

i'll check again tonight but I don't think SEP/local astrometry draws the rectangle correctly: None of the methods agree:
kstars +130.34º


latest astap (+?) 49.07º but when called from ekos using builtin or SEP star extraction, -130.93º

latst siril -130.93º

nova online -48.0º

Alfred is right! As I mentioned in my summary the most reliable method is 'Internal SEP & Local/Online Astrometry'! I'm working with this combination for one year now without any glitches.
Let's have a look at the results of alacant:

- Internal SEP & Local Astrometry : Orientation = -49.06° => PA = 130.94° [OK]
- Latest Siril : Orientation = -130.93° => PA = 130.93° [OK]
- Nova online : Orientation = -48.9° => PA = 131.1° [OK] within error range
- Builtin Method(?) & Astap : Orientation = 49.07° => PA = -130.93° [WRONG] I still don't know why

"Internal SEP & Local/Online Astrometry"

Thanks Toni/Alfred so much for your time on this.

That's what it shall be then:)
Cheers

Ok, I now think Astap does handle RowOrder, but returns the orientation without "reverting"! This means the result of Astap is correct if you include the information of the small graphics you can see right above the image:
For IC1318A and for NGC6914

But as you can see "N to E" is not yet reverted (or mirrored) to the correct presentation or better

Reverting the image means turning negativ the presented orientation and that leads to the correct -144.3°° for IC1318A and -49.07° for NGC6914. So the results presented in the UI of Astap are - as a whole - correct but the presented or returned figures alone are NOTt!! The align module, however, needs the correct orientation angle which is only present if the N to E is oriented correctly.
Of course it would be easy to change the code of EKOS to address the situation, but isn't it legal to request a correct orientation result from an application like Astap, is it?

"...isn't it legal to request a correct orientation result from an application like Astap..."

Thanks again Toni

I've asked on the ASTAP discord forum.
sourceforge.net/p/astap-program/discussi...l/thread/4876d14d73/

Cheers and clear skies.

Hi Toni,

Thank you for your great investigation and report on this. I talked with Robert Lancaster and he said that he wasn't sure about the different interpretation for rotations & position angles given by each solver. Now that you have identified the discrepancies, do you think we can compensate for them in StellarSolver so that all the angles reported back to the client (KStars in this instance) are consistent & correct for all the various solver types?

I still would prefer that all the solver return a correct result! It is bad to correct a bug with another one.
I still think, that Astap is not working right (but perhaps there are other people who can supply evidence of the opposite!).
Just look at the debug messages of alacant's IC1318A:
With Astrometry:
"Solver RA (303.86150) DEC (41.55998) Orientation (-144.26732) Pixel Scale (1.19290) Parity (neg)"
With Astap:
"Solver RA (303.86020) DEC (41.56064) Orientation (144.26970) Pixel Scale (1.19540) Parity (neg)"

One of them has to be wrong. Since Astrometry works uncomplainingly for more than a year with my gear, I would say that Astap is buggy: Following my argumentation of the previous posts either orientation or parity of Astap is wrong. I suspect that parity is wrong and should be positive. If we can rely on the correctness of parity the best solution would be to include the - so far - unused parity variable (called "eastToTheRight" in align.cpp), when the PA is determined with "SolverUtils::rotationToPositionAngle(orientation, eastToTheRight))". This routine could calculate then the PA according the math rules.

I was talking about correcting this at StellarSolver level since it is the one interfacing with all the different backend solvers. So not a change in Ekos, but a change in StellarSolver so that the results are consistent across all solvers.

Ok, it is of course viable way to let stellarsolver produce the correct return values for negative parity always, so no changes are needed in EKOS. Nevertheless the problem of the wrong values of Astap remains.

Totally agree, any issue should be tackled at its root, if possible. I hope Alacant's report to the ASTAP guys will yield the desired improvement.

Here some further information regarding the returned orientation angle in ASTAP (from www.hnsky.org/astap.htm#transformation ), which corroborates my assumption that ASTAP does not handle flipped images.
<citation>
The same angle is reported in the header as keyword CROTA2. So the angle for flipped images is reported as if the image is "unflipped horizontal".

<citation end>

So ASTAP leaves the burden with the correct calculation to the programmer...
<citation>
To get a rotation angle for a flipped image, programmers could do the following:
<code>if CDELT1*CDELT2>0 then
rotation:=-CROTA2 //flipped image
else
rotation:=CROTA2</code>
<citation end>
... and I'm asking why?