Question on reported rotation angle
Stacking program, astrometric (plate) solver, fits file viewer
Brought to you by:
han59
Menu
▾
▴
ASTAP shows the north and east cardinal point indicator correctly for my files but curiously instead of 0deg when pointing up (as shown in the help file) it reports180deg and instead of 180deg when pointing down it shows 0deg.
What is wrong in the header that is causing this?
The north-east arrow is always showing the orientation of the image in the viewer. So if you flip the image vertical or horizontal (menu view) the north-east arrow follows.
The angle indicated in degrees is the image angle of the file. It is not influenced by the view setting. So it is the angle of the astronomical solution. But note the rotation direction is reversed if the image is flipped. See this explanation:
http://www.hnsky.org/astap.htm#viewer_angle
Han
It is those tables in the help file I have been using as the reference. The issue is that with no viewer flip in either axis I get N up and E left 180deg for my chosen camera orientation, scope pointing east. Scope pointing west I get N down and E right 0deg. So the indicator is exactly as expected but the reported angle is not?
I assume the solver reports a negative CDELT2, Something like this:
CDELT1 = -3.703579029698E-004 / X pixel size (deg)
CDELT2 = 3.704295309601E-004 / Y pixel size (deg)
If your image is flipped you see a letter F near the east-north indicator.
The solution is not only the angle but also if the image is flipped horizontal or vertical. What solution is put in the file header? Note that for FITS images the first pixel [1,1] in the file is the left bottom position. If your files are written upside down then the angle is 180 degrees off.
The solution orientation is defined by these:
CDELT1 = -3.703579029698E-004 / X pixel size (deg)
CDELT2 = 3.704295309601E-004 / Y pixel size (deg)
CROTA1 = 3.456491666111E-001 / Image twist X axis (deg)
CROTA2 = 3.415071437840E-001 / Image twist Y axis (deg) E of N if not flipped.
ASTAP reports only CROTA2 near the east-north indicator.
Han
Okay, that sounds like what is going on. I recall when I first started using CCDiel with an ASI294 I complained to Patrick that the images in being saved were vertically flipped. He said it had something to do with the way ZWO have the ASCOM driver set up. He made a change which I think involved what you talk about but I will have to go back and have a look at the posts in the CCDciel group. The FITS header has a field that reports the order of the pixels that probably ASTAP does not read.
Okay, that sounds like what is going on. I recall when I first started using CCDiel with an ASI294 I complained to Patrick that the images in being saved were vertically flipped. He said it had something to do with the way ZWO have the ASCOM driver set up. He made a change which I think involved what you talk about but I will have to go back and have a look at the posts in the CCDciel group. The FITS header has a field that reports the order of the pixels that probably ASTAP does not read.
Hmmm, I think there was a glich with sourceforge...
Also a glitch in my brain, I meant horizontally flipped ie top to bottom swap.
Patrick added ROWORDER= 'TOP-DOWN' to the fits header which indicates when 1,1 is top left, see attached. At the time I did not realize that APP assumed this as the normal state of a FITS so it was happily displaying something inverse to CCDciel and ASTAP and also the FITS standard! And that is what was confusing me.
APP now recognizes ROWORDER and behaves as needed. Can ASTAP do the same?
Hi David. sorry for the late reply. ASTAP recognized the ROWORDER keyword. But it only influences the Bayer pattern. It should not flip the image as some programs do (so wrongly).
Please upgrade to ASTAP version 2025.03.07. The previous versions have a bug in sigma clip stacking of OSC images.
Cheers, Han
I guess I'm still confused. I thought that was why I get the following indication from ASTAP. It says the image is flipped in one of the axis (F) and shows 180deg when it should show 0deg. The image is most certainly not flipped in any axis....
Then you have the view flipped. Twice flipped is no-flip. See attached. Uncheck both view flip setting
Cheers, Han
Last edit: han.k 2025-03-08
Okay, at some point I must have set that in ASTAP and forgot - it seems to be stay set with no indication which is a little confusing. Anyway, it seems all the other programs I use flip the preview image according to ROWORDER (including CCDciel). At least I now understand why ASTAP is reporting the angle it does.
In CCDciel you can also flip the view with the two small arrows near the left bottom. I'm pretty sure CCDCiel does not flip the image based on ROWORDER.
The convention is that for FITS images pixel 1,1 is at the left bottom side of the screen. But some programs do not follow it any more.
I think you are right to be punctilious about this Han, why add to the confusion! But it does result in an incorrect angle relative to the actual physical object image - but I understand why now and have moved on.
Regarding CCDciel, prior to my request to Patrick it was behaving consistent with ASTAP and I had to vertically flip the preview in both programs - I was unaware of the usual behaviour of ASCOM camera drivers at the time. CCDciel now has several changes that possibly add to the confusion as a result of my prodding - 1/ it has an option to vertically flip the image coming from a camera ASCOM driver (all the cmos cameras I've used return TOP-DOWN images, CCDciel offers to make them consistent with the FITS standard) 2/ the viewer now defaults to a vertically flipped imaged (those arrows you refer to function the same as those in ASTAP and are persistent between sessions but unlike ASTAP it is clear in CCDciel when they are active. I do not have them active), 3/ loading an image with ROWORDER missing or ="TOP-DOWN" results in the behavior described in 2/, when ="BOTTOM-UP" it does not invert the image in the viewer 4/ exporting an image to Cartes de Ciel from CCDciel gives the right orientation, but loading one that has been saved that is ="TOP-DOWN" inverts the image so that program does not seem to be doing anything with ROWORDER.
I don't use 1/ because it makes all the other programs I use flip the image. For example, APP seems to have always assumed "TOP-DOWN" and ignored ROWORDER. After a user that was using a camera that was actually FITS compliant complained, it now inverts the image if ="BOTTOM-UP" like CCDciel does!
I understand PI behaves like APP, and with the liberties NINA seems to take with standards I would not be surprised if it behaves the same way as well.