Last night I started imaging and then the transparency dropped so that when SGP tried to plate solve in order to center, the plate solve failed. I then loaded an image from the previous night and tried to plate solve it. It too failed. Thus began an investigation that has produced results that I don’t understand.
When I open an image in SGP and right click on the image to plate solve it, the Object field in the pop-up window is blank. This is the first puzzling thing because the open image has a file name. And, the FITS header of the image contains the field “Object” with value, in this case, of M78. Why is the Object field not populated with the object’s name - either the file name or the FITS header value?
If I click Solve, the PlateSolve 2.29 window appears with the correct coordinates of the object (in this case M78). However, the Image File Name is of the form “psXSolve_n.fit”, where “n” is an integer that increments starting at zero. Why is PlateSolve trying to solve a file “psXSolve_n.fit”? By the way these are real FITS files that can be located on the C drive. In my case they are in C:\Users<name>\AppData\Local\SequenceGenerator\Temp.
If I allow the solve to proceed, it fails and does not find a solution. However, if I right click on the same M78 image and enter “M78” (without the quotes) in the Object field and then click Solve, the plate solve immediately succeeds even though the Image File Name in the PlateSolve 2.29 window is STILL “psXSolve_n.fit” and NOT M78 despite having entered M78 in the Plate Solve window obtained by right clicking on the image. How is it that entering the name in the Object field enables it to work even though the PlateSolve 2.29 window reports that it is solving a different FITS file? By the way, the value in the Object field of the Plate Solve window does have to be M78. It won’t work if I enter something else.
My conjecture is that SGP or PlateSolve 2.29 is creating a copy of the displayed image file and is working on the copy. And, SGP or PlateSolve 2.29 is using a database accessed by the value in the Object field as the key to control the plate solve process. In fact, I can delete the entered values in the RA and Dec fields in the Plate Solve window and as long as the Object field has the correct value entered, then Plate Solve 2.29 works just fine.
In conclusion it would be very helpful if SGP would populate the Object field of the Plate Solve window with the “Object” value in the FITS header. Is that not logical? That field value is critical to Plate Solve working and the value is available to SGP in the FITS header.
I have two setups: one shared remote in Spain which use PS2 and one in my home observatory which uses PinPoint.
The shared remote rig images unguided and uses a large model. All of the plate solves for these models are provided by PS2. We use the F&M wizard for target setting. It works succesfully every time. None of the issues you describe above are evident in this setup and it works flawlessly with SGP 2.6.
At home, I have just upgraded to the new SGP3. I thought as an aid to help you with your issue, after I had upgraded and registered the PC, I opened a new sequence with a profile and switched the plate solver to PS2. I then opened up an old Ha sub taken with the same image scale as my profile using SGP, right clicked with PS2 to solve. This solved within 2 or 3 seconds and then up popped the box confirming the solve and asking me whether I wanted to use this as solve as the centre for my target. I never had to enter any object name or file name for this to work.
The above is obviously a very quick test without any detailed analysis. However I’m sure you know that many users have PS2 as their solver and do not encounter the issues you seem to be having. I guess this points to something amiss with your specific setup.
Whilst this doesn’t get you any nearer to resolving your issues above, I hope it reassures you that SGP does work.
Was the image you were trying to solve from the “previous night” taken with SGP? You imply this is the case but just want to check.
Hi Barry,
Thank you for your reply to my post. And thank you for performing your test.
Yes, the image I used from the previous night was taken with SGP.
I was not using the F&M wizard either night. I was using SGP 2.6.0.25.
You mention that you did not have to enter any object name in the image you asked SGP (via PS) to plate solve. It is key to know whether the Object field was blank in the Plate Solve window that pops up upon right clicking the open image. Can you perhaps just try it and see, please? If it is not blank, and if in fact, it contains the right name of the object, then, yes, it will work. However, if it is blank I suspect you may find that it does not work. In my case the Object field in the pop-up window is blank and the plate solve fails. If I manually enter the correct name of the object in the Object field, then plate solve does work. But, that is not really an automated process it is? And, automation is the purpose of SGP, I believe.
I do not know the internals of SGP, but I suspect that this is related to another issue I have found which is that SGP is not using the Object field in the way it needs to perform some of its functions. In the case of the Plate Solve window SGP is not using the Object field in the FITS header to populate the Object field in the Plate Solve window. In the case of creating a target list from an Astroplanner import, SGP is not using the Object ID field from the XML file to populate the Target name and the target name appears as “Unknown”. This despite the fact that the SGP user manual says to use Object ID to export from Astroplanner. And, indeed, I believe this is the right field to use because the “Name” field in Astroplanner can sometimes be blank and can sometimes be a name not commonly used, e.g. De Mairan’s Nebula versus M43. If the Astroplanner “Name” field is included in the export is used, then SGP will use that in the Target List but, again, that is not what the SGP documentation says to use, and it is not generally the name commonly used to refer to the object.
I believe in both of these cases Object [ID] is the correct field to use. It is in the FITS header. It is what the SGP User Manual prescribes. It results in the most commonly used identifier of the object. And, it is what is the name of the field in the pop-up Plate Solve window.
The Object field was blank, I’m reasonably confident.
I have never had to enter a name of the object in any plate solver I have used over the years, from Astrotortilla, Elbrus, PinPoint or PS2. Many objects have multiple catalogue names; I don’t know anything about the Object field in the FITS standard and it seems quite impractical in any software application that a User has to understand such to operate it. For me, I’m delighted that the solver doesn’t label a solve with a default object name as this allows me to name the target as I see fit.
If you’re right clicking on an image captured by SGP and your chosen solver will not solve it and call up the dialogue box to allow you to use the solve as the target co-ordinates, something is amiss with your settings.
I should have time to check again tomorrow (my local time is 11:30pm at the moment and sleep is calling).
If the object field in your right-click pop-up Plate Solve window is blank and Plate Solve still solves the image taken during a previous observing session, then it will require someone with knowledge of the SGP internals (Jared or Ken probably) to dig into what the difference is that allows SGP to solve your image and not mine.
It might be that the problem has been fixed in Version 3. You said you performed the test after you upgraded to Version 3. If the problem is fixed in Version 3, that is terrific. I have not yet upgraded, but plan to as soon as I can. Then, I can perform my test again and see what happens.
I’m having a similar issue trying to plate solve off an image taken by SG Pro. Except in my case, the popup dialog box is not populating the RA and DEC coordinates even though they are in the FITS Header. As such, the plate solve fails every time. What’s really weird is this is only happening with my newer ASI294MM camera; images taken with my older ASI294MC successfully populate the RA and DEC coordinates and solve quickly. Finally, I compared the FITS headers for the 294MC image, (taken in Apr 2021) and the 294MM image, (taken last night), and the FITS headers are formatted significantly differently. Why are the FITS headers formatted differently? And, even though the format is different for the 294MM, why can’t PS2 read the RA and DEC coordinates from its FITS Header? The 2 FITS headers are attached.
Restarted SG Pro to verify no remaining issues from the rocky session I had last night. Paradoxically, now the same 294MM image that failed to populate the RA and DEC coordinates from a right click Plate Solve now populates those coordinates and plate solves fine? Further confusing the issue: both the 294MC image and the 294MM image have reformatted their FITS headers?
Anyway, for right now, I’m just glad plate solving works for both images as I had a LOT of trouble getting plate solving to work with the 294MM last night. Hopefully, it’ll work now…
