incorrect values for CRVAL1 and CRVAL2

[MikeB838]

Dear Robin,

with my new PlayerOne Uranus-C Pro camera, in the Fits header there are new key words included. Besides others: CRVAL1 and CRVAL2.

I use Astrometrica to measure Asteroid positions and seemingly with a new version of Astrometrica the starting position is a part off the image now,
so I asked a question in the Astrometrica user group.

Herbert Raab checked my image (http://www.twus.de/Green_Stack_16bits_5frames_150s.zip) and found out that Astrometrica now
can use CRVAL1 and CRVAL2 (instead of OBJCTRA and OBJCTDEC) for the center of the image.
But the values of CRVAL1 and OBJCTRA and the values of CRVAL2 and OBJCTDEC differ.

OBJCTRA and OBJCTDEC (and RA and DEC) give the correct center of the image (both in Jnow), but not CRVAL1 and CRVAL2.

Please could you check if there is a problem with the values of CRVAL1 and CRVAL2?

Thank you very much!

best regards,

Michael

[admin]

Hi Michael,

let me dig into that a bit - not clear why the value is coming out different to the OBJECTRA/DEC co-ordinates, as it is supposed to use the co-ordinates of the center point of the image according to the plate solve mapping.

cheers,

Robin

[admin]

Hi Michael,

OK, this is going to be interesting to track down...

If I solve that image again and re-write the FITS file, I get the expected center point values of RA=~343.704 and Dec=~15.122 for the CRVAL1 and CRVAL2 keywords. I have tested with four different plate solving engines (Astap, Astrotortilla, PS3 and SharpSolve) and they all agree on those co-ordinates.

So, the reason that the values are different in your FITS file must come down to the sequence of actions leading up to the save. SharpCap calculates those values by taking the most recent plate solving data and then adjusting to account for any mount movements since the last plate solve. Since there is an error (particularly in RA) in your file but not when re-tested, I think there must have been a mount movement after plate solving but before saving (or a sync or some other mount adjustment that was not being properly accounted for). We can tell that the mount is not at the image co-ordinates, since the RA/DEC headers in the FITS (which are read directly from the mount) are different:

Code: Select all

    RA      =   343.99854166666665 / Epoch : JNOW
    DEC     =   15.257227777777778 / Epoch : JNOW

These differences amount to more than the offset between J2000 and JNOW.

Is there any way you can locate the SharpCap log file for the session where you saved this image? SharpCap usually keeps old log files for up to 30 days, so there is a chance it is still in the SharpCap log file folder. That could have enough information to reveal where the mount was when the last plate solve happened, what action was taken at that point, etc.

thanks,

Robin

[MikeB838]

Hi Robin,

thank you very much for looking!

Attached is my log file, the stack is named '995' and starts at line 4105. It took 4 tries to get the final stack and at line 4245 the stack of the image of
my last post begins.

I must admit that I sometimes start a slew before saving. I had never thought about it, but I had no such big offsets before (when CRVAL1 and
CRVAL2 were not available). Only small offsets, but that was only if I did not perform a plate solving before taking the stack (eg. when I only
had to slew a smaller amount to the next target and see it - not in the center, but close enough to the center of the image).
Here with '995' I did do some plate solvings.

Hopefully you can see the problem!

cheers,
Michael

Log_2025-08-23T21_31_51-14684.zip

(118.88 KiB) Downloaded 18 times

[admin]

Hi Michael,

the thing that I found was that the 'sync' didn't seem to be taking in the plate solve and sync operation for some reason... A log extract below of the plate solve just before the problem file

Code: Select all

Debug  	01:33:17.326536	#1 	Notification (Status=Warning): Solving: Refined solution found at RA=22:55:19.9,Dec=+15:07:15 against tile at RA=23:04:36.9,Dec=+18:00:00		
Info   	01:33:17.328325	#1 	Mount reports JNOW, converting results position from RA=22:55:19.9,Dec=+15:07:15 (J2000)								
Info   	01:33:17.328522	#1 	Conversion result is RA=22:56:37.6,Dec=+15:15:34 (JNOW)																	
Info   	01:33:17.328615	#1 	Frame center calculated at RA=22:55:19.9,Dec=+15:07:15 (J2000)															
Info   	01:33:17.328773	#1 	Frame center converted to JNOW : RA=22:56:37.6,Dec=+15:15:34															
Info   	01:33:17.329017	#1 	Recording Sky Orientation Mapping from Plate solving at RA=22:56:02.2,Dec=+15:15:33										
Info   	01:33:17.329092	#1 	PixelSize is {Width=2.9, Height=2.9}, Side of Pier is WestSideLookingEast, Mapping is Rotation (xAxis):178.92, Rotation (yAxis): -180.98 Flip: F
Info   	01:33:17.329180	#1 	Plate solve info with center at RA=22:56:37.6,Dec=+15:15:34 recorded against mount position RA=22:56:01.1,Dec=+15:15:33, mapping data is TileCen
Debug  	01:33:17.329468	#1 	Notification (Status=OK): Plate solve succeeded, position found to be RA=22:56:37.6,Dec=+15:15:34 (JNOW, offset of 0.15 degrees), field of view 

Info   	01:33:17.329629	#1 	Field solved to RA=22:56:37.6,Dec=+15:15:34, field Size {Width=0.41572198, Height=0.23502953}							
Info   	01:33:18.225086	#1 	MessageBox : 'Please Confirm' SharpCap is currently live stacking. Are you sure you want to move the mount? => user choice Yes				
Warning	01:33:18.225181	#1 	MessageBox: SharpCap is currently live stacking. Are you sure you want to move the mount?								
Warning	01:33:18.225234	#1 	MessageBox: User Chose:Yes		
																						
Info   	01:33:19.225744	#1 	Before Sync mount is at RA=22:56:04.2,Dec=+15:15:33																		
Info   	01:33:20.824374	#1 	After Sync mount is at RA=22:56:06.2,Dec=+15:15:33																		
Info   	01:33:20.824490	#1 	Frame center calculated at RA=22:55:19.9,Dec=+15:07:15 (J2000)															
Info   	01:33:20.824689	#1 	Frame center converted to JNOW : RA=22:56:37.6,Dec=+15:15:34															
Info   	01:33:20.824953	#1 	Recording Sky Orientation Mapping from Plate solving at RA=22:56:06.2,Dec=+15:15:33										
Info   	01:33:20.825031	#1 	PixelSize is {Width=2.9, Height=2.9}, Side of Pier is WestSideLookingEast, Mapping is Rotation (xAxis):178.92, Rotation (yAxis): -180.98 Flip: F
Info   	01:33:20.825121	#1 	Plate solve info with center at RA=22:56:37.6,Dec=+15:15:34 recorded against mount position RA=22:56:01.1,Dec=+15:15:33, mapping data is TileCen

Debug  	01:33:20.825197	#1 	Notification (Status=OK): Mount synced to RA=22:56:37.6,Dec=+15:15:34, re-centering on target at RA=22:56:01.2,Dec=+15:15:33 (offset of 0.15 deg
Info   	01:33:21.825537	#1 	Before Slew mount is at RA=22:56:01.7,Dec=+15:15:34																		
Warning	01:33:51.089940	#36	Failed to align with the reference frame.																				
Error  	01:33:51.090091	#36	Failed to calculate alignment.																							
Warning	01:33:51.091815	#36	Frame not stacked because : Could not align																				
Info   	01:33:51.091952	#36	Dropped frames : 32 of type LiveStackReject																				
Info   	01:34:01.623972	#53	=='.NET TP Worker' (New Thread)
Info   	01:34:01.624007	#53	Live stacking reset.																									
Debug  	01:34:01.645330	#1 	Notification (Status=OK): Live Stack reset, starting a new stack of '995'.												
Info   	01:34:02.622673	#1 	After Slew mount is at RA=22:56:00.7,Dec=+15:15:26																		
Info   	01:34:02.623507	#1 	Toolbar/Menu input : SharpCap.ViewModels.Actions.SolveAndResyncAction  complete											

I have put blank lines before the log lines of interest. We can see that the plate solve result comes out as RA=22:56:37.6,Dec=+15:15:34 (line starting 'Field Solved to', and that SharpCap thinks it has asked the mount to sync to those co-ordinates (actually, they will be converted to JNOW, but that's not critical). However, the two lines 'Before Sync mount is at' and 'After Sync mount is at' are showing basically the same co-ordinates, so the sync seems not to have changed the mount co-ordinates.

The same co-ordinate is showing up as the mount position before the slew too ('Before Slew Mount is at').

If this is correct then it probably explains the CRVAL issues - SharpCap thinks the mount co-ordinates have been corrected by the 'sync', but they haven't and are still offset from the true pointing, which means the calculated offsets to the plate solve results are wrong.

Are you using the iOptron mount with a pointing model? On some ASCOM drivers, that prevents the 'Sync' command from doing anything. I am surprised that the plate solve and resync does anything given the above data.

cheers,

Robin

[MikeB838]

Hi Robin,

I remember that I had a night where I had to do some plate solves to reach my target. May be this is for this target '995' as I used more than 1
plate solve.
Normally when I press "Plate Solve and Resync" my iOptron slews to the correct target without problems.
And '995' was not the only target where Astrometrica does not get the correct center.
I will check this this afternoon and take a look into the log if the same does happen there and tell you the targets.
And I'm not aware of a pointing model. I will check that too.

For now thank you very much for your great support!!

cheers,
Michael

[admin]

Hi Michael,

will be interesting to hear what you find out. As I was digging through what had gone on, I started to work out that using the plate solving results from previous images when saving has all sorts of complexities that I am not fully handling.

Things like what if the mount is guiding? That changes the co-ordinates of the mount but keeps the image fixed, so adjusting for the offset in mount position when calculating the CRVAL numbers would be wrong. But SharpCap may well not know if the mount is being guided or not...

Or, if you are live stacking, changes in the mount position between the first stack frame and the save don't need to be taken into account when saving the stack (but do for saving raw frames)... It's all rather scary!

cheers,

Robin

[MikeB838]

Hi Robin,

it took longer than I thought and I'm running in circles and I scratch my head.

I found several things:
1. the availability of CRVAL1 and CRVAL2 is not a function of the camera (as I thought), but they are available if I do a plate solve
2. at line 3829 of the log file one can find a complete sync command fail
3. for target '16834' OBJCTDEC and DEC are completely wrong (+89° instead of 44° with CRVAL2) (please see: 16834_fits_header.txt)

In my log files one can see that for 9 of the 14 Asteroid images I did not make a plate solve, but then there are no CRVAL values in the header.
That may reduce your concern.
I attach the fits header of all the 14 asteroid observations of that night as text files, in case you may take a look.

When I load an image in Astrometrica it shows the center coordinates (in J2000), which it calculates from CRVAL1 and CRVAL2 (if availabe),
or from RA/Dec or OBJCTRA/OBJCTDEC.
For 3 of the 14 images the center is okay, for 5 images it is almost okay and 6 are way off. The okay ones do not(!) correspond to the plate solved ones.

I made a LibreOffice calc-sheet with the values of the 14 asteroid observations that night. May be it is interessting?

Then I find:
In line 1644 of the log for target 2100 (first occurrence): Info 23:00:44.970086 #1 After Slew mount is at RA=19:22:47.8,Dec=+21:30:42
That seem to be JNow values and OBJCTRA/OBJCTDEC and RA/Dec show the same values.
But CRVAL1 and CRVAL2 show: 19h 21m 38,447s and 21° 26´ 36,368´´
When I convert the RA/Dec values to J2000, I get: 19h 21m 40.78s and 21° 27' 40.41''
(I use https://clearskytonight.com/projects/as ... ssion.html)
That is closer to the CRVAL values.
Can it be that CRVAL1 and CRVAL2 are not in JNow but in J2000? Astrometrica assumes Jnow and converts it to J2000 and uses
19h 20m 32.4s and 21° 23´39´´ and failed to center the Asteroid.

And in this case I did not move the scope before, but took another stack of the same target afterwards.

But for targets without CRVAL Astrometrica also fails. I continue scratching...

To me it looks like there are some problems on different sides which accidentally come together!?

I do not use the 2 or 3 star polar alignment of the iOptron. I use the iPolar scope to align the axis to the north pole.
The first move to a target 90 or 120 degrees away gives me a first offset of 1 to 3 degrees. After resync and smaller
moves the scope comes very near to the target. But with the small FOV (0.42x0.23 degrees) I have to plate solve from time
to time.

I think I have to check the following the next time I'm at the scope:
1. do not move before save
2. compare with and without plate solve

Sorry for the long post, many thanks and best regards,
Michael

[admin]

Hi Michael,

it's going to take me a while to fully investigate your info above, but in the meantime, I will just clarify a few points.

1) The RA/DEC and OBJECTRA/OBJECTDEC header values come straight from the values read from the mount co-ordinates, so you will get JNOW values and they will be whatever the ASCOM driver reported at the point in time when the frame was received from the camera - SharpCap does not adjust these values, just passes them through.

2) The CRVAL1/CRVAL2 always come from plate solving initially, and always refer to J2000. They don't exist alone though, they have to be read with the CRPIX1/2 values (which specify the pixel in the image that the CRVAL1/2 apply to). They also support the CD1_1, CD1_2, etc keywords, which record information that allows the position of any pixel to be calculated in the image (or conversely allows any co-ordinate to be converted to a pixel position). As I mentioned previously these values are offset to try to take account of mount movements since the plate solve happened, so they are not purely from plate solving.

I am wondering whether a different approach is the right thing here... I can think of two options

1) Plate solve the actual frame using SharpSolve before saving (provided we have a recent plate solve to provide reference position). This should be fast as I can restrict the search to a very small radius of the known position, and would give exact values for all the CR headers with no offsets needed

2) Make the whole writing of the CR stuff optional

Or maybe both...

cheers,

Robin

[MikeB838]

Hi Robin,

thank you for looking and your infos!

If CRVAL1/2 are in J2000 that can be one of the problems: as I understand Herbert Raab in his answer (https://groups.io/g/astrometrica/message/8661), Astrometrica converts the CRVAL1/2 to J2000 because it finds the EQUINOX value in the header!?

CRPIX1/2 point to the center in the images, so this should be okay.

At first making the writing of the CR stuff optional seems interesting, BUT: Astrometrica also fails to center some of the images without the
CR stuff, so the problem seems to be somewhere else (too).

cheers,
Michael