incorrect values for CRVAL1 and CRVAL2

[admin]

Hi,

I will check that again...

cheers,

Robin

[admin]

Hi Mike,

this turned out to be an interesting rabbit hole that went down a *long* way...

I started by trying some images in various other plate solving tools to get rotation values from them in the hope that I would get consistent answers from all the other tools and could then be confident that if I made SharpCap give the same results, everything would be good. It didn't turn out to work that way...

In terms of reporting the angle for 'up is <XXX> degrees east of north' for plate solved images, I discovered the following:

* SharpCap was actually reporting the angle west of north, not east of north - I think this was because my mental picture of an angle 'east of north' was based on looking down at a map, where you rotate clockwise as the 'east of north' angle increases. However, for the sky, you are looking upwards - like looking at a map from below - so the 'east of north' angle runs anticlockwise (also, see Astap, below)

* The online solver at 'nova.astrometry.net' displays FITS images upside down, so it's definition of 'up' is wrong - it's what would be down in the original FITS image. However, apart from that, it gets the rotation correct

* PlateSolve3 sometimes gets the answer right, but I found a case where giving it an image that had been mirror flipped left<->right gave a completely different orientation to the unflipped image. Of course, both should be the same because the 'up' direction in both the original and mirrored image is identical

* Astap seems to give the same west-of-north results as SharpCap - this might have helped convince me that my original interpretation is correct.

I have now corrected the calculated and displayed orientation in SharpCap to be properly 'East-of-North' and manually checked a range of images to be sure that the value presented matches what you would expect from looking at the orientation of the image relative the the sky axes. I also have tested a range of images across all supported plate solve engines in SharpCap to make sure that the reported orientation and mapping matrix come out the same from the different engines.

If you save a FITS image with the 'Bottom-up' option turned on in the SharpCap settings for FITS standard compatibility then other tools like 'xy2sky' from the wcstools package will correctly calculate sky positions from pixel positions (you have to remember that they expect the Y co-ordinate to be measured from the bottom up, not the top down).

The new changes are in 4.1.13789, which is now available for download.

cheers,

Robin

[MikeB838]

Hi Robin,

that sounds interesting (and like a lot of work). The seemingly easiest things often come out as the hardest ones

Thanks a lot for the new update, I will try it soon and see how it affects the work with Astrometrica.

cheers,

MIchael

[MikeB838]

Hi Robin,

I managed to test with the new version of SC (V4.1.13789 64bit).

It works a lot better and I can use the stacks in Astrometrica as I could before.
Nevertheless it seems to be possible to improve it (see 2.) and there is an aspect, that I do not quite understand (see 1.).

----------------------

1. I have an image of Asteroid 1916, shot left of the meridian (Pierside = West) and North is at the bottom of the image.
I have saved the Fits in Top-Down order.
SCSolver and PlateSolve3 find: "Orientation : up is 180.9 degrees E of N" or rather "Orientation : up is 180.7 degrees E of N"
The Fits header says: CROTA1/2 = 359.07534653222103
As I understand it: about 180° seems correct, but about 0° not. Or do I miss something?
Astonishingly Astrometrica rotated the image correctly and I do not have to rotate it manually. So it is fine for me in the moment.
The next clear night I will try a shot left of the meridian with saving bottom-up.

----------------------

2. All images of the night were good to handle in Astrometrica (center not far off), but I noticed in the image
of Asteroid 1916 that in Astrometrica only in the right half of the image reference stars were found. A sign that the center is outside of the image.
I checked the values in the Fits header and - if I had calculated it right - it seems that some values are a little bit off:

Plate solve in SC: RA=00:24:33.9,Dec=+25:42:59 (J2000)
Conversion to JNow (https://clearskytonight.com/projects/as ... ssion.html)
Corrected Right Ascension = 0h 25m 54.84s
Corrected Declination = 25° 51' 32.07'

I converted both values:
J2000 => RA = 6.14125, Dec = 25.716388889
JNow => RA = 6.4785, Dec = 25.858908333

but in the Fits Header I see:
RA = 6.486416666666667 / Epoch : JNOW
DEC = 25.8625 / Epoch : JNOW
CRVAL1 = 6.730000912576919 / Reference Pixel RA (deg)
CRVAL2 = 25.88090155438818 / Reference Pixel Dec (deg)
OBJCTDEC= '+25 51 45.000' / Epoch : JNOW
OBJCTRA = '00 25 56.000' / Epoch : JNOW
DATE-AVG= '2025-10-02T22:54:24.7520152' / System Clock:Est. Frame Mid Point
EQUINOX = 2025.7548402103141 /

First CRVAL1 != RA and CRVAL2 != DEC and both do not match my values.

I changed CRVAL1/2 in the Fits header to my values (RA = 6.4785, Dec = 25.858908333), loaded the image again in Astrometrica,
Astrometrica calculates the J2000 value for the center to RA = 00 24 34.1 and Dec = 25 43 01
(which is near to the plate solve values) and now reference stars can be seen in the whole image (= the center position seems to be correct now).

May be you can check your calculations again? Thank you very much!!

----------------------

I have found two more things in the new version but I have opened a new bug report.

Cheers,
Michael

[admin]

Hi Mike,

glad to hear that we are making progress - hopefully not too many more things to be sorted

Item 1) is expected because you are saving 'top down'. Most FITS software still does not understand the ROWORDER header, so will display the 'top down' saved images flipped vertically compared to the view in SharpCap. That means that 'UP' effectively changes direction once the image is saved, so that 'up' in those saved images is 180 degrees opposed to 'up' in SharpCap. Hence the differing rotation angles - you do need to set the saving option to 'bottom up' for full consistency, but that is incompatible with previous SharpCap behaviour.

Item 2) is more interesting. The first thing to note is that the CRVAL1/2 headers come from a different source to the RA/DEC headers, so that it is reasonable for them to be different under some circumstances....

CRVAL1/2 come from plate solving (with a possible offset adjustment if the mount has been moved since the plate solving happened)

RA/DEC/OBJECTRA/OBJECTDEC come from the mount's co-ordinate readout.

If you have synced the mount recently (and close to the current position) then the two should be the same or very close. If you have not synced recently and nearby then the difference between the two is basically a measurement of the current pointing error of the mount (where it is really pointing in CRVAL1/2 against where it thinks it is pointing in RA/DEC). Whether this could apply obviously depends on your workflow in the run up to the observation.

If you have synced the mount and you are getting this error then the next thing to consider is 'have you moved the mount at all since the last plate solve?'. SharpCap is supposed to be compensating for that, but it's the sort of place that there could be an issue (compensating the wrong way? or somehow the compensation is being bypassed).

If you could think about how those two possibilities might (or might not) be possible with the workflow you used and let me know, I will know if I need to look into the code and where.

cheers,

Robin

[MikeB838]

Hi Robin,

thanks for your answers!

Item 1) okay, I will play with top-down, buttom-up in case I will need it. In the moment it seems to match Astrometrica and I'm happy
I only wanted to let you know.

Item 2) Because I did the meridian flip directly before taking the image of Asteroid 1916, I shot one frame, then made a "Tools => Plate Solve and Resync" and then shot my stack. I think that the plate solve values I saved that night (and showed in my last post), were the values after taking the stack (and not the values from the plate solve which moves the mount). I think my mount moves about half of a degree after the first Plate solve.
If this value is taken, that will explain the differences.

So I did not move the mount after the plate solve before taking the stack. But can be the move of the plate solve the problem?

I hope that helps, please let me know, if you need any other information and thank you very much for your help!!

cheers,
Mike

[admin]

Hi Mike,

yes, it's possible that the movement for the plate solve + resync might be the cause (I'd hope not - it's supposed to be dealt with, but who knows). I will have a test the next time we get some clear sky, as this is one of those things that really doesn't lend itself to testing in simulation.

cheers,

Robin

[admin]

Ah yes, I should mention that if it is the offset from the sync causing the problem, a second plate solve after the re-center has completed should resolve the issue. On the other hand, if the issue is still present after a second plate solve, it's probably caused by someting else!

cheers,

Robin

[MikeB838]

Hi Robin,

good idea that I will try the next time at the telscope, thanks!

cheers,
Mike

[admin]

Hi Mike,

got some (mostly) clear sky last night so managed to test this out and I found that the correction that I had thought was being added was actually bypassed due to the way the code worked, so no adjustment was being made to CRVAL1/2 for any mount movements since the plate solve operation

I have now corrected this, and version 4.1.13800 should work much better for these values. I was still seeing differences between the CRVAL1 and RA (also CRVAL2 and DEC), but these were now of the order of a few arc seconds. Note that in the new version, the CR/CD headers will only be added if the mount is within 1 degree of the plate solve location - for larger offsets, plate solving again is required. This is to try to ensure that the sort of errors that arise due to the attempt to correct for the movement do not become too large.

cheers,

Robin