Until recently, PlateSolve2 tended to always work, and worked quickly. A week ago or so, I began using my coma corrector, and accordingly reset the image scale. However, since this change I’ve never been able to get a successful PlateSolve2 solution, meaning I can’t sync, can’t center, and can’t do successful meridian flips. I thought perhaps I was getting a lot of hot pixels registered as stars so I played with the settings to eliminate that problem and viewing the image suggests I’m only using real stars; still no luck. So tonight between 6 and 7 PM I did a few experiments with plate solving on a 600-sec integrated image. PlateSolve2 either fails (usually) or gives an incorrect solution (occasionally), although the astrometry.net blind failover is working so I know my starting coordinates and image scale are not bad. I must be doing something stupid, but at this point I’m stuck and thought I’d best ask for help. I haven’t done the obvious test of removing the coma corrector to see if things still work without it, because solving really ought to work even with the slight scale change. My starting parameters and settings are attached, and my logfile and the image I’m using for testing are at this Dropbox link: Dropbox - File Deleted
Thanks in advance for any help!
The issue here does not seem to be settings related, but rather more about quality of data. Neither PlateSolve2, PlateSolve3, Pinpoint or Elbrus is capable of solving the image you posted. It seems Astrometry.NET uses a more robust star detection routine… that works after a bit.
I think the primary issue here is that you appear to be imaging with an OSC… I can’t tell for sure because you are using a Nebulosity ASCOM Driver (what is that?). The plate solvers, I would guess, are choking on the bayer pattern. Anyhow, I think you will have much better luck in moderately star-poor areas like this one if you bin at 2x2… this should rid the solve input data of weird artifacts and give you a better chance of solving.
Here is the stuff I think confuses solvers when in star-poor areas (this is from your image):
Thanks for your reply! Yes, you are exactly right. I’m using a Meade DSI IIc, which is a OSC. No doubt the Bayer pattern is causing problems. Because SGP doesn’t directly support the DSI IIc and as far as I can find Meade never produced an ASCOM driver for it, the only way I’ve been able to use it with SGP is by running Nebulosity 4.0.4, mounting the camera in Nebulosity, and using the Nebulosity ASCOM driver, which makes Nebulosity appear as a camera to ASCOM. I can mount that in SGP. It’s definitely sub-optimal in that I also have frequent hangs when downloading images this way. I’d love to bin the camera for plate solving and focusing, but all the binning options (except 1x1) are greyed out, which probably makes sense for a very low-end OSC.
I’ve continued to experiment, and even went back to some older images that didn’t use the coma corrector. I used to easily get plate solves with them, but it sure doesn’t work now. I just can’t think what might have changed. I was originally using 2.4.0.25 when I started having plate solve issues. I’ve since installed 2.5.0.19, but that didn’t help. Astrometry.NET and ANSVR both work, but of course are slow and I’m guessing probably wouldn’t work with shorter exposures (the ones I tested with were 10 minute subs).
Do I have any options short of getting a better camera? (I’d love to do that, and I’m working on softening her up, but it’s going to be a hard sell to the boss!)
I finally found the solution. It turns out the problem was not the Bayer matrix after all. Rather, it was the aspect ratio setting I was using in PlateSolve2. This is set at 1 by default. However, my cheap DSI IIc imaging camera does not have square pixels. They are 8.6 microns wide by 8.3 microns tall, so you have to set the aspect ratio to 8.3/8.6=0.965. I think I even messed with this parameter before, but inverted it (I tried 8.6/8.3). Anyway, with it set correctly, plate solves work every time.
