For context, I'm extremely new to SharpCap, and generally new to astronomy and astrophotography, so it'd be best to assume I know basically nothing.
I'm aware that "plate solving" is the process of determining which stars are in an image, then determining the centroid orientation of that image based on those stars.
I'm also aware of the polar alignment feature of SharpCap. To the untrained eye, it sure looks like SharpCap plate solves frames at many frames a second to achieve the pose estimate then used to determine current camera pointing axis. But I know SharpCap supports a handful of external libraries, one of which must be installed, to support the actual "plate solving" workflow, and all of which use Astrometry.net under the hood (I have downloaded and installed this myself to play around with on the command line, so I'm a bit familiar with that software stack and processing workflow).
That implies that Astrometry.net or its algorithms are NOT used for orientation estimation in the polar alignment module.
Assuming that's true, why is that? I assume astrometry is less performant, but how and why? I know you can limit Astrometry's search scope by both orientation and field of view, so those restrictions alone don't seem explain the choice.
What algorithm is implemented for orientation determination during polar alignment, and how is it more performant than Astrometry? I'd love to hear as many nerdy details as anyone can share!
What's the difference between polar alignment and plate solving?
Re: What's the difference between polar alignment and plate solving?
Hi Alex,
The polar axis alignment is fixed at the time you set up the mount. This is not always exact. SharpCap has a tool that enables you adjust the mount by using a camera on the finder. This is partly manual and doesn't use any plate solving. Its a physical adjustment. I check the polar alignment about once a year on my observatory pier.
Plate solving will position the camera frame (by moving the RA-Dec) to the coordinates you selected. Gotos are not exact for a number reasons - Polar axis not exact or has moved, telescope or optical flexing, atmospheric refraction. So plate solving gets you on target for your imaging.
If you have slackened off the clutches for any reason or you have a mobile setup, then plate solve will take away a lot of aggravation. I use All Sky Plate Solver.
Hope this helps a bit
Tim
C11, QHY174gps, EQ8/Eqmod, SkyMapPro
The polar axis alignment is fixed at the time you set up the mount. This is not always exact. SharpCap has a tool that enables you adjust the mount by using a camera on the finder. This is partly manual and doesn't use any plate solving. Its a physical adjustment. I check the polar alignment about once a year on my observatory pier.
Plate solving will position the camera frame (by moving the RA-Dec) to the coordinates you selected. Gotos are not exact for a number reasons - Polar axis not exact or has moved, telescope or optical flexing, atmospheric refraction. So plate solving gets you on target for your imaging.
If you have slackened off the clutches for any reason or you have a mobile setup, then plate solve will take away a lot of aggravation. I use All Sky Plate Solver.
Hope this helps a bit
Tim
C11, QHY174gps, EQ8/Eqmod, SkyMapPro
Re: What's the difference between polar alignment and plate solving?
Thank you! So you're saying tracking during an exposure DOESN'T use plate solving, it just bumps your axis based on the displacement of previously detected stars?
Anyway I'm particularly curious about the difference in the underlying algorithm used for polar alignment (which does detect precise stars, since it picks out polaris?) and plate solving.
Anyway I'm particularly curious about the difference in the underlying algorithm used for polar alignment (which does detect precise stars, since it picks out polaris?) and plate solving.
-
admin
- Site Admin
- Posts: 13350
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: What's the difference between polar alignment and plate solving?
Hi,
SharpCap has a built-in plate solving algorithm for polar alignment that I designed to solve the specific problem of solving within a limited radius of the celestial pole and to give really fast performance.
The key differences to a more general purpose plate solving tool like Astap are :
* SharpCap only loads data for stars within 7 degrees of the pole and down to magnitude 13 (about 20000 stars for each hemisphere)
* The effects of curvature of spherical co-ordinates can be ignored by using a polar projection only going out to a limited radius (7 degrees)
* The number of stars is small enough that the whole database can be loaded into memory and then converted into a form that gives really quick look-up, allowing plate solving within this area to be achieved in a few milliseconds or tens of milliseconds.
Other than that, the way it works is similar to other plate solving tools - select ground of four stars to make a quadrilateral and try to match the quadrilateral shapes in the observer star database with those in the detected stars in the image.
cheers,
Robin
SharpCap has a built-in plate solving algorithm for polar alignment that I designed to solve the specific problem of solving within a limited radius of the celestial pole and to give really fast performance.
The key differences to a more general purpose plate solving tool like Astap are :
* SharpCap only loads data for stars within 7 degrees of the pole and down to magnitude 13 (about 20000 stars for each hemisphere)
* The effects of curvature of spherical co-ordinates can be ignored by using a polar projection only going out to a limited radius (7 degrees)
* The number of stars is small enough that the whole database can be loaded into memory and then converted into a form that gives really quick look-up, allowing plate solving within this area to be achieved in a few milliseconds or tens of milliseconds.
Other than that, the way it works is similar to other plate solving tools - select ground of four stars to make a quadrilateral and try to match the quadrilateral shapes in the observer star database with those in the detected stars in the image.
cheers,
Robin
Re: What's the difference between polar alignment and plate solving?
Extremely helpful, thank you!
* 20k stars for each hemisphere down to mag 13 sounds quite large to me. I guess the idea there is that, if you knew you were solving with a wide field of view, you could use a MASSIVELY smaller catalog, but in the case of SharpCap, you might be solving a very narrow field of view from a guide scope so you MUST support that many stars to ensure 15 are in view over the supported FOV range. Speaking of which - I'm fooling around with a camera that has 5* or so FOV, which SharpCap seems quite happy with, even though the manual says the supported FOV range is 0.5* to 2.5*?
* Just so I'm clear on the spherical coordinates thing - the idea there is that if you supported FOVs wider than a 7deg radius (so 14deg across), you'd have to account for barrel distortion during the search, whereas inside that 14deg FOV you can just ignore it and use a linear uncertainty for every star regardless of position within the frame? I'm unclear if you're saying this is a factor that limits camera FOV or that limits initial displacement from the pole (which wouldn't make sense to me).
* As far as the catalog size: So you're saying something like Astrometry is limited in performance because it has to pick a search catalog, load it into memory, check all the possibilities, then discard it and repeat for the next catalog if that search failed. In contrast, you can load the 20k stars, which all fit and thus require no iops overhead?
Would you be willing to go into anymore depth about your search algorithm implementation? I'm terribly curious just because it's SO much faster than astrometry even for well-constrained inputs to their pipeline (i.e. tight bounds on image FOV and initial orientation). I'm curious how your implementation differs at a lower level than https://arxiv.org/pdf/0910.2233.pdf
Thanks so much for indulging me!
* 20k stars for each hemisphere down to mag 13 sounds quite large to me. I guess the idea there is that, if you knew you were solving with a wide field of view, you could use a MASSIVELY smaller catalog, but in the case of SharpCap, you might be solving a very narrow field of view from a guide scope so you MUST support that many stars to ensure 15 are in view over the supported FOV range. Speaking of which - I'm fooling around with a camera that has 5* or so FOV, which SharpCap seems quite happy with, even though the manual says the supported FOV range is 0.5* to 2.5*?
* Just so I'm clear on the spherical coordinates thing - the idea there is that if you supported FOVs wider than a 7deg radius (so 14deg across), you'd have to account for barrel distortion during the search, whereas inside that 14deg FOV you can just ignore it and use a linear uncertainty for every star regardless of position within the frame? I'm unclear if you're saying this is a factor that limits camera FOV or that limits initial displacement from the pole (which wouldn't make sense to me).
* As far as the catalog size: So you're saying something like Astrometry is limited in performance because it has to pick a search catalog, load it into memory, check all the possibilities, then discard it and repeat for the next catalog if that search failed. In contrast, you can load the 20k stars, which all fit and thus require no iops overhead?
Would you be willing to go into anymore depth about your search algorithm implementation? I'm terribly curious just because it's SO much faster than astrometry even for well-constrained inputs to their pipeline (i.e. tight bounds on image FOV and initial orientation). I'm curious how your implementation differs at a lower level than https://arxiv.org/pdf/0910.2233.pdf
Thanks so much for indulging me!
Re: What's the difference between polar alignment and plate solving?
Hi Alexw,
Sorry, I miss-informed you about sharpcap not using plate solve in the polar axis routine. Thanks for the clarification/reminder Robin!
Alexw replied to me (i think) : "So you're saying tracking during an exposure DOESN'T use plate solving, it just bumps your axis based on the displacement of previously detected stars?"
No, i dont believe i said that !! For tracking i use an autoguider, unless you are using the sharpcap feature tracking but I'm way out of my depth there.
Best of luck with your setup. Sharpcap changed by imaging "life". When i bought the QHy gps camera for occultation work, i had to use Sharpcap to run it. This move me up to a new level of camera and mount control.
Cheers - Tim
Sorry, I miss-informed you about sharpcap not using plate solve in the polar axis routine. Thanks for the clarification/reminder Robin!
Alexw replied to me (i think) : "So you're saying tracking during an exposure DOESN'T use plate solving, it just bumps your axis based on the displacement of previously detected stars?"
No, i dont believe i said that !! For tracking i use an autoguider, unless you are using the sharpcap feature tracking but I'm way out of my depth there.
Best of luck with your setup. Sharpcap changed by imaging "life". When i bought the QHy gps camera for occultation work, i had to use Sharpcap to run it. This move me up to a new level of camera and mount control.
Cheers - Tim
-
admin
- Site Admin
- Posts: 13350
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: What's the difference between polar alignment and plate solving?
Hi,
yes, the procedure is very similar to the one described in the paper, although I use a slightly different approach for geometrical hashing that generates a code that is also invariant under mirroring.
Speed comes from only having to check a small fraction of the sky (about 0.4% of the total sky) as well as the simplifications in terms of ignoring spherical geometry already described (think of how a small coin sat on top of a soccer ball is a good approximation to the shape of the ball over that small area where it sits, whereas a 15cm diameter disk sat on a soccer ball is not a good approximation to the cuved surface of the ball). Also the fact that many other plate solving applications use star data down to magnitude 17 or even further means that they have much more data (and hence more possibilities) to work through.
With any plate solving operation you have to allow some tolerance for distortion in the image (from lens distortions). If you have a particularly 'bad' lens in terms of distortion then the solving might struggle with star patterns that stretch across the whole image, but will probably succeed with smaller localised patterns.
cheers,
Robin
yes, the procedure is very similar to the one described in the paper, although I use a slightly different approach for geometrical hashing that generates a code that is also invariant under mirroring.
Speed comes from only having to check a small fraction of the sky (about 0.4% of the total sky) as well as the simplifications in terms of ignoring spherical geometry already described (think of how a small coin sat on top of a soccer ball is a good approximation to the shape of the ball over that small area where it sits, whereas a 15cm diameter disk sat on a soccer ball is not a good approximation to the cuved surface of the ball). Also the fact that many other plate solving applications use star data down to magnitude 17 or even further means that they have much more data (and hence more possibilities) to work through.
With any plate solving operation you have to allow some tolerance for distortion in the image (from lens distortions). If you have a particularly 'bad' lens in terms of distortion then the solving might struggle with star patterns that stretch across the whole image, but will probably succeed with smaller localised patterns.
cheers,
Robin