PEMPRO Support

Sequence Generator Feature Requests
21

Concerning APCC, it would be up to A-P to ask me to put in support for SGPro. If plate solving is added to the SGPro ReST APi then I think that would make adding SGPro very desirable.

And yes, the video interface will be put back in within the next few builds.

-Ray

22

It would not be that hard to doā€¦ If you need it let us know and we can get it out pretty quickly.

1 Like
23

Hi Ken (and Jared),

I have heard back from Marj and Roland from A-P and they have authorized me to add camera support via SGPro to APCC. They have also authorized me to use SGProā€™s plate solving feature via the ReST API, should you guys choose to implement that. But please donā€™t kill yourselves trying to get that done quickly though as they have been mostly focussed on getting their new CP4 controller out so they havenā€™t had a chance to validate the last few minor APCC releases I have provided them. Once the CP4 controller is released then things should start to move much faster in regards to APCC.

That said, when you do have something ready let me know so I can program the API and test. And thank you guys again for the wonderful support!

-Ray

2 Likes
24

@rgralak That is good news. I donā€™t think it will be too hard to provide access to the SGPro solving system.

1 Like
25

This is great to hear! Thanks for pursuing it!

26

@rgralak

I added the plumbing for API based plate solving tonight (not fully working). The first implementation of this will:

  • Require that the user selects a plate solver via the SGPro UI (no solver selections through the API yet)
  • Require the path to a 16-bit unsigned FITS file to solveā€¦ meaning there will be no shortcut option to solve the current FOV. This will require taking as image (as you do now), then sending that image to the plate solve API. Later we might add a shortcut endpoint that does these things for you in the correct order and just returns solve data.
  • Require hints for Ra, Dec and image scale
  • Provide a boolean indicating if hints should be extracted from the FITS header data. If this is true, you can choose to override them with your own data too.
  • Provide a boolean indicating if you want a blind solve (no hints required if this is true).

Have I missed anything that will impede your integration?

1 Like
27

Hi Ken

Yes, that sounds like the right list. There might be some other parameters, like the catalog min/max star magnitudes to use, but I donā€™t think all plate solving implementations support that so I think those could be user defined in the user interface, if available.

-Ray

28

True. Those all sound like very Pinpoint specific params. Not that we canā€™t support them, but youā€™re rightā€¦ they do vary by solver. Iā€™ll think about how to let the API alter theseā€¦ for now, you are correct, the user can set these in SGPro and the API call to solve will use those settings.

29

@rgralak This is complete-ish (will be in 2.5.0.18). Just need to add provision to abort a solve. It functions in an asynchrnous manner much like the request to acpture an image. Here is a response payload:

{
  "Success": true,
  "Message": "Matched 374 Stars.",
  "Ra": 2.5576199821336,
  "Dec": 61.2853912778935,
  "Scale": 2.8485461875368,
  "Angle": 198.034412527393,
  "TimeToSolve": 21.4122714
}
30

Hi Ken,

About the angle, will all of the plate solving applications report camera angle the same way?

Also, what happens (if anything) if the image is mirrored vertically or horizontally?

-Ray

31

Yes, All solvers report east of north.

Iā€™m dealing with this issue in another bug so Iā€™d like to say yes, but right now I think thatā€™s still an issue.

32

@rgralak

With the exception of some possible irregularities for flipped images, this should be ready for prime time in 2.5.0.18 (at least good enough for initial integration). Everything is documented here:

http://127.0.0.1:59590/metadata

Of interest are:

  • SgSolveImage
  • SgGetSolvedImageData
  • SgAbortSolve