SharpCap Forums

Hi Robin,

Perhaps a stretch to call this a bug. But I had trouble with plate solving last night, so I thought I'd check a few things in the daylight using the Folder Camera. It uses FITS files, which have info in the header for camera pixels and pixel size, as well as RA (OBJCTRA) and DEC (OBJTDEC). It doesn't include FL, but that is specified in the SC settings for the Plate Solver. So, it would seem SC has all the info it needs for a plate solve with known FOV and initial RA/DEC.

However, the solve (using ASTAP) fails. The logs show that SC is starting a "blind solve", i.e. with no prior knowledge of position? And it seems to also not know the FOV (seems to select 1 degree). See attachment.

Is a plate-solve using the Folder Camera something that should work, or has that not made it onto your (long) to do list?

I checked everything by using Sky Simulator and the ASCOM Telescope simulator and also setup the simulator camera size to match. This worked well and solved every time.

So I returned to the Folder Camera, but kept the simulator mount. That way I could drive the (virtual) mount to the same coordinates as the Folder FITS file images. So it should 'know' some initial RA.DEC now. But that did not seem to help.

Cheers, Chris.

Hi Chris,

I suspect that what is happening is that the folder monitor camera is not bothering to read the pixel size headers from the FITS files. Without a known pixel size, you can't work out the FOV even if SharpCap has the correct focal length set up, so the plate solving reverts to 'try all image sizes' mode. Actually, what happens here with Astap is that SharpCap runs Astap twice - first with options to say 'use the last measured FOV' and if that fails with options to say 'try a range of FOV'. If you have a mount connected then SharpCap will use the mount co-ordinates as a hint for the plate solving (even for a blind solve). However, I have noted that Astap's strength seems to be very fast results when the FOV and rough co-ordinates are known, as opposed to Astrometry.net based engines which seem to take longer but get the results in the end.

I will have to look at loading the pixel size - shouldn't be too hard and I think it will help. Obviously this requires FITS files to be loaded rather than PNG etc.

cheers,

Robin

Hi Robin,

The other thing about the Folder Camera that could change is mounting the additional Hardware. If the FITS file becomes the prime source of RA/DEC, pixel size and Focuser value, there is no real reason to (try to) mount any real hardware. Connecting to both Mount and Focuser could be skipped. I usually dismiss the errors for Mount and Focuser, when using the Folder Camera. For Plate-Solving, it would be a good idea to remove any ambiguity about where values for position, FOV or focus come from.

Cheers, Chris.

Hi Chris,

I have to be careful here, because one of the use cases is to pull in images from unsupported cameras that are being written to file as they are taken. In that case, you *are* running a live imaging session via the folder monitor camera, so connecting to hardare etc may be perfectly valid.

cheers,

Robin

Hi Robin,

Interesting. Then how would we “tell” SC that we want the position, focus, details to come from FITS header instead of from hardware? Would it be enough to just select “None” for mount and focuser hardware?

Chris.

Hi Chris,

I think the problem here is that this pushes the limits of what my idea for the folder monitor camera was - the two use cases I had in mind were

* the one I described above about monitoring a folder for newly created image files saved by some other application to support cameras that SharpCap doesn't normally support

and

* Reprocessing raw data captured either in SharpCap or another appication through live stacking

Neither of them really have a place for caring much about the co-ordinates or other header information in the fits files - with a couple of exceptions like exposure length.

I guess what I am saying, in a roundabout way, is that there isn't currently a way to do what you are asking, and I'm also struggling to see how it is something that is going to be widely used if it was available, sorry.

cheers,

Robin

OK, no worries. I understand that you’re juggling many different demands. And the use of the Folder Camera to handle unsupported cameras is a very important capacity.

I guess I’ll need to find other methods to explore why plate solve and sync works great many nights, and then fails completely at other times.

Cheers, Chris.

Turning it around, the other approach is to make the "Plate solve (only)" menu tool more flexible. Perhaps make it pop-up a window, with all Plate Solve assumptions shown, where mostly we simply click on "Start". It's a bit like your "Start Capture" window that remembers what was done before.

But in the case of the Folder Camera, the assumptions shown could be edited (e.g. FL, FOV, RA/DEC, ...), or even add a button to retrieve RA/DEC and pixel size from FITS? At least we know what is passed to ASTAP, etc. That then narrows down the diagnosis to image quality issues.

Cheers, Chris.