×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

alignment: wrong orientation shown on kstars

  • Posts: 333
  • Thank you received: 92

If you flip a transparent image also the visible orientation will flip. However the actual orientation in the sky can not be flipped. Any inverting telescope or camera does not change the orientation in the sky so the angle is better reported unflipped.


The CROTA2 is only part of the solution. In is a pair with CDELTA2. You can't specify the orientation of an image with one value like CROTA2. You need two values.

If you want an uniform report by all solvers, then you should use something like this:
if (cd1_1*cd2_2-cd1_2*cd2_1)>=0 then sign:=+1 else sign:=-1;
rotation:= -arctan2(cd2_1,sign*cd1_1)*180/pi; //arctan2 returns arctangent of (y/x)

See www.hnsky.org/astap.htm#viewer_angle

Han


The following user(s) said Thank You: Jasem Mutlaq, alacant
9 months 1 week ago #94090
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
About the orientation reported by nova.astrometry.net. This one is dependent on the type of image. The same image uploaded as PNG or FITS results in a 180 degrees different reported. I have reported this a bug but the Astrometry.net team is not interested in correcting it. They say the solution in CD1_1...keywords is correct. That is correct. The problem lies in the angle reported in the online report. Not in the header solution.

The bug report is changed to feature request:
github.com/dstndstn/astrometry.net/issues/151

Han
The following user(s) said Thank You: alacant
9 months 1 week ago #94093

Please Log in or Create an account to join the conversation.

  • Posts: 970
  • Thank you received: 94
Hi Han, everyone

Thanks for your replies.

Unfortunately, as it stands ATM, I can't use ASTAP, my preferred solver from within kstars, bacause of the orientation/flip issue.
Until a definitive solution is obtained, for now, would it be possible to consider altering the ASTAP orientation so that it agrees with the other solvers in kstars?

OTC, would it be possible for a temporary solution from the kstars developers?

TIA for your time.
Last edit: 9 months 1 week ago by alacant. Reason: Ortografía
9 months 1 week ago #94146

Please Log in or Create an account to join the conversation.

  • Posts: 270
  • Thank you received: 74
"Unfortunately, as it stands ATM, I can't use ASTAP, my preferred solver from within kstars, bacause of the orientation/flip issue.Until a definitive solution is obtained, for now, would it be possible to consider altering the ASTAP orientation so that it agrees with the other solvers in kstars?"
I already mentioned in a previous post, that I would prefer that ASTAP returns the standard orientation for astronomic images. All the more so due to the fact. that orientation is needed to rotate the camera frame into the right angle an not only for information purposes.
With all my respect to Han's work, it's strange enough that the column "New angle reported by ASTAP" in Han's table has indeed values with a negative sign, while ASTAP always returns positive angles in my tests.

OTC, would it be possible for a temporary solution from the kstars developers?
We should ask Robert Lancaster, the author of 'Stellarsolver', if he is willing to address the situation. Until now, he did not bring himself in. Indeed I would be very interested to know his opinion.
The following user(s) said Thank You: alacant
Last edit: 9 months 1 week ago by Toni Schriber.
9 months 1 week ago #94164

Please Log in or Create an account to join the conversation.

The following user(s) said Thank You: alacant
9 months 1 week ago #94170

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
The Astrometry.net solver gives you only the four CD keyword for the solution orientation and scale (plus the reference pixel CRPIX1, CRPIX2 and position CRVAL1, CRVAL2) . They provide all the information. If you use them why can't do the same with ASTAP? Then fix all discrepancies. All solvers give you the correct and same solution. But you have to process at least two header keywords and not just one for orientation.

Stellar solver is using the Astrometry,net code. I don't know what Robert did for additional processing for orientation. Hopefully he can clarify this. But to standardize you better move/copy his code line which is a function(CD1_1, CD1_2, CD2_1, CD2_2) to Ekos and use it for all solvers. Then there will be no discrepancies.


Note:
The reason CROTA2 changed in ASTAP is that for flipped images it was wrong for the classic solution keywords (CROTA1, CROTA2, CDELT1, CDELT2). To simulate the old situation it would in principle require a new keyword something like ANGLE because I don't want to ASTAP to produce wrong classic keyword solutions. Since Astrometry.net doesn't provide any angle directly (the classic keywords are missing) it was much better and elegant to refer to the modern CD keywords. So the suggestion is just to use them and ignore CROTA2.


Han
The following user(s) said Thank You: alacant
9 months 1 week ago #94173

Please Log in or Create an account to join the conversation.

  • Posts: 970
  • Thank you received: 94
"I sent a PR to StelalrSolver: github.com/rlancaste/stellarsolver/pull/127"

Thanks for the update.
Here is a test with the new code. ASTAP now returns both the correct PA in EKOS and has the correctly rotated solver rectangle when viewed in kstars.
Thanks again.

Log attached.


The following user(s) said Thank You: han
Last edit: 9 months 1 week ago by alacant. Reason: ortografía
9 months 1 week ago #94174
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 2884
  • Thank you received: 818
Hey guys, sorry I have been a bit busy the last few months with a master's degree. I appreciate the work you put in to diagnose the issue and I accepted the pull request. I am sorry I did not get into this discussion sooner.

github.com/rlancaste/stellarsolver/pull/127

Please let me know if this doesn't solve it or if we need to do some more.
9 months 1 week ago #94178

Please Log in or Create an account to join the conversation.

  • Posts: 270
  • Thank you received: 74
Hi all
There are good news! I finally succeeded in catching the discrepancies for all the solver methods (except 'watney').
Look at the return values for "orientation" (or PA) for Version 3.6.5 with alacant's IC1318A with correct orientation -144.3°:
(Negative image parity means "normal" image, while positive image parity means vertically mirrored image)
Internal SEP & Internal Solver:
Solver RA (303.86135) DEC (41.56001) Orientation (-144.26796) Pixel Scale (1.19292) Image Parity (neg)
Solver RA (303.86136) DEC (41.56000) Orientation (-144.26690) Pixel Scale (1.19292) Image Parity (pos)
 
Internal SEP & Local Astrometry (ver 0.93):
Solver RA (303.86149) DEC (41.56003) Orientation (-144.26691) Pixel Scale (1.19289) Image Parity (neg)
Solver RA (303.86148) DEC (41.56003) Orientation (-144.26577) Pixel Scale (1.19291) Image Parity (pos)
 
Internal SEP & Online Astrometry:
Solver RA (303.86196) DEC (41.56078) Orientation (-144.26825) Pixel Scale (1.19344) Image Parity (neg)
Solver RA (303.86089) DEC (41.56055) Orientation (144.26577) Pixel Scale (1.19291) Image Parity (pos)
 
Builtin method & Online Astrometry:
Solver RA (303.86143) DEC (41.56006) Orientation (324.26826) Pixel Scale (1.19282) Image Parity (neg)
Solver RA (303.86145) DEC (41.56005) Orientation (-324.26779) Pixel Scale (1.19282) Image Parity (pos)
 
Builtin method & Local Astrometry (ver 0.93):
Solver RA (303.86150) DEC (41.55998) Orientation (-144.26732) Pixel Scale (1.19290) Image Parity (neg)
Solver RA (303.86150) DEC (41.55998) Orientation (-144.26661) Pixel Scale (1.19290) Image Parity (pos)
 
Builtin method & Local ASTAP:
Solver RA (303.86021) DEC (41.56064) Orientation (144.26987) Pixel Scale (1.19540) Image Parity (neg)
Solver RA (303.86131) DEC (41.56009) Orientation (144.26714) Pixel Scale (-1.19543) Image Parity (pos)
 
nova.astrometry.net (interactive):
Solver RA (303.86021) DEC (41.56064) Orientation (-144.26987) Pixel Scale (1.19540) Image Parity (neg)
Solver RA (303.86131) DEC (41.56009) Orientation (-144.26714) Pixel Scale (-1.19543) Image Parity (pos)
As you can see, 'Online Astrometry" and 'ASTAP' return wrong orientation values (see present thread).

Solutions:
Builtin method & Local ASTAP:
Jasem's PR ( github.com/rlancaste/stellarsolver/pull/127 ) rectifies the problem.

Builtin method & Online Astrometry:
Unfortunately this option sends ALWAYS a JPEG to 'Online Astrometry' resulting in wrong orientation by 180° (see Han's note github.com/dstndstn/astrometry.net/issues/151 ). Unchecking "Upload JPG" in 'Align Options'/External & Online Programs' has no effect! I propose to upload only FITS and cancel the possibility to upload JPEG. (What was the reason to introduce this feature?). This leads to a correct absolute value of the orientation angle of 144.3°.

Internal SEP|Builtin method & Online Astrometry:
There is a strange conversion of the orientation in github.com/rlancaste/stellarsolver/blob/...nlinesolver.cpp#L524 . Commenting this line gives correct orientation angles of -144.3° for negative and positive image parity! I propose to omit this conversion.

If I find some time, I will put a PR for the last two cases.
The following user(s) said Thank You: Alfred
Last edit: 9 months 6 days ago by Toni Schriber.
9 months 6 days ago #94215

Please Log in or Create an account to join the conversation.

  • Posts: 2884
  • Thank you received: 818
Thank you very much for investigating. To answer your question, I believe that the upload of JPG images to astrometry.net instead of FITS files for the online solver predated my work on StellarSolver. That code was originally part of KStars until it was moved into StellarSolver to simplify and modularize KStars. I think that the reasoning was that many users image in the field or in situations where their bandwidth is not very large and so uploading a huge FITS file would take too long and a JPG would upload much faster. Since I made StellarSolver as you know, many more options exist for solving and I personally would not upload any images to astrometry.net. If I was going to use the online solver and I was concerned about bandwidth, I would probably extract the stars using internal SEP and then upload the star locations. That way you are just uploading a text file. That option did not exist in KStars before StellarSolver. Now that there are more options, we can certainly stop uploading JPEG images if it causes inaccuracies with the online solver.
9 months 5 days ago #94221

Please Log in or Create an account to join the conversation.

  • Posts: 970
  • Thank you received: 94
Regression with ASTAP version 2023.08.14, 64 bit

Hi everyone
Latest ASTAP reverts to the old behaviour; the orientation never settles. The alignment loops forever.
log: 17:26 (attached)

With local atrometry, all is still well:
log: 17:30 (attached)

Would it be possible to revert ASTAP to converge on the correct PA?

TIA,
Steve
Last edit: 8 months 2 weeks ago by alacant.
8 months 2 weeks ago #94823
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
?? The ASTAP CROTA2 reporting has not changed for at least 6 month. The CD keywords reporting (preferred) has not changed for years.
8 months 2 weeks ago #94825

Please Log in or Create an account to join the conversation.

Time to create page: 0.710 seconds