Pinpoint and Gemini

When I image with narrow fields (12 x 15 arc minutes) in fairly star poor regions, I get a lot of plate solve failures with Pinpoint. I traced it to the following and hope you can add a proposed fix.

All the plate solvers I’ve used (Pinpoint and Plate Solve 2) return J2000 coordinates and want a hint in those if the field is narrow. A while back, I asked the questions about Epochs and was told to use J2000 for SGPro pointing. No problems and I set my Gemini to expect J2000. However, even though Gemini is happy to receive and precess J2000 for pointing, it will always return JNow (this is the case for Gemini 1, Rene said he may add an option to return J2000 if needed for Gemini 2). I think SGPro uses this to feed the plate solvers, causing failures (thankfully there is the Astrometry.net fallback although it takes time).

Would it be possible to have an option under the plate solvers or mount to precess what is returned from the mount to J2000 to feed the plate solvers when needed. I think this will reduce the failure rate.

I’ve tested this on images that failed to solve with Pinpoint…when I fed the standalone the JNow as a center point, It usually failed unless I selected a spiral search with 50% expansion. When I fed it the J2000, it solved without problems. The precession routine would not have to be very precise.

Frank Z…

You can also set your plate solvers to return JNow. I believe Elbrus and Pinpoint both have this option.

Thanks,
Jared

Jared,

I looked through the Pinpoint docs and for the Equinox property it is only J2000. It expects J2000 for the “hint” or at least a wide enough field so it can find enough matches to fit if it is fed anything else. I never had a problem with Pinpoint when using larger fields and getting JNow from the scope, but with smaller fields, it seems to be a problem. Being able to allow a spiral scan in Pinpoint may also be solution instead of precessing the input to J2000.

Thanks,

Frank Z…

You might also ask if this can be addressed in the Gemini ASCOM driver. It
seems that if it can take J2000 as an input it should convert on output. Or
at least do this in the ASCOM driver. That way the scope could always be
JNow but it could convert to J2000 in the ASCOM driver.

Jared Wellman
Co-Owner and Developer
Main Sequence Software
www.mainsequencesoftware.com

Jared,

Another way that may be easier to implement is through the ASCOM Novas31 Precession method. I don’t know if you use any of this in SGPro, but it would be a simple method call if desired. I have to look into it a bit more (long day after x country flight), but as the method already exists, it won’t require any driver change to the Gemini and maybe give a bit more flexibility in setting up sequences.

One implementation:

Get scope position from mount
If not in J2000, (based on a checkbox option), then use Novas to Precess to J2000.
Feed into the plate solver.

Frank Z…

Couldn’t we solve this with a better star catalog too?

How? Isn’t the issue that the earth wobbles? Pretty sure the locations of
objects change no matter your catalog.

Jared Wellman
Co-Owner and Developer
Main Sequence Software
www.mainsequencesoftware.com

They have better data on the dim stars which means his narrow FOV solves better. Unless it’s really the J2000 issue, but there are lots of people with C14s imaging who have solved this problem with other software.

I thought this was the whole reason people used those catalogs.

The problem is not as much as the narrow field of a C14 type scope, but the position the plate solver uses as a starting point. My 14 inch SCT is mounted on a Titan with a Gemini controller. Even though the Gemini is set to accept J2000 from SGPro for pointing, it returns its location in JNow. Other mount controllers may not work this way. If your mount is set for J2000 and returns the position in J2000, then all will be fine as far as the plate solvers. Pinpoint and Platesolve 2 are quite robust as long as they get a good plate scale and position as a starting point.

But the difference between J2000 and JNow is around 13 arc minutes near the ecliptic plane. If there is not enough catalog overlap, then there is little chance of a fit especially in star poor regions where I’m more likely to image galaxies with the 14 inch’s 12 x 15 arc minute FOV.

I played around a bit with the Pinpoint standalone. I grabbed some images with SGPro at the same location/binning/exposure where pinpoint failed. When I entered the J2000, all worked fine. With JNow, it was quite sensitive to the catalog expansion value. If I use 20% it fails, 25% if fits. Default for the engine is 30%, so why didn’t Pinpoint work in SGPro? Also, the star catalog did not matter. The GSC and A2 catalogs both performed the same as far as success. For the short exposures used for centering,you’ll get close to the same number of good stars in each catalog.

So what is the best fix for SGPro in these situations (short of blind solve)?

The best would be to have a flag where if set would precess what the scope sends to J2000 before seeding the solver. There is an ASCOM method in the Novas module. Only Jared can tell us how much of a pain this would be to implement.

Next is the spiral scan in Pinpoint as that caught all. However, I don’t see a property or method in the Pinpoint engine to use this so it may be unique to the standalone and difficult to implement in the engine.

A third would be to have another setup feature for Pinpoint where one can set the catalog expansion property. It can be opened in the narrow field profiles (to up to 80%) and closed up in the widefield profiles.

The JNow/J2000 difference will only get worse and those those of us with Gemini controllers (and maybe others), it would be nice to get a fix to this.

Thanks,
Frank Z…