New Feature : SharpSolve - SharpCap's new built-in plate solver

[Jean-Francois]

Hello Robin,

0.1° ? If I'm kidding ? ... yes and no.

Some people (very few, but maybe in the future more people) do spectrographic observations with SharpCap.
It is necessary to perform the guiding on the slit itself. So it is necessary to have the correct view in the guiding camera (that images the slit).
If you have a telescope with 2000 mm focal and a guiding camera with 4 mm size, then you will have 0.1° field on the guiding camera.
Note that the relay optics that reimages the slit on the guiding camera has maybe not so good quality. The result is strong distorted stars in the corner.

I did in the past mainly spectroscopic observation with my Williams Optics Megrez 90 and a QHY-200 guiding camera.
In this case the short side of the camera has 0.33° field, But with the poor images quality it is necessary to cut to ~ 0.2°.
I used ASTAP and it was fast each time possible to have a plate solve on the guiding camera (but with a short telescope focal).

For the exposure time ... 20s, 30s or 60s ... really ? I target to 2s max 5s.
OK, I used a Newton with FD=2.9 reducer or a RASA8" with FD=2. But 60s ... that could be longer as the exposure time.

Regards,
Jean-Francois

[admin]

@Jean-Francois,

most people working at small FOV will be using f/10 not f/20, so that explains the exposure differences. For wider fields or faster optics 5s or so should be fine I think. It's all about getting enough exposure to bring stars above the noise level (60 to 100 good stars seems to work best).

@Han,

my quads are the complex sort - I set up a co-ordinate system based on the two stars that are further from each other and then (with a couple of tweaks to ensure that the hash codes are not disturbed by mirror imaging) the co-ordinates of the two remaing stars make your hash codes. Actually the slowest part is working out the 6 distances between the possible pairs of stars, so maybe just simple distances would not gain much.

Multi-threading is based on tiles - there are 522 tiles in the index and SharpCap will order them in distance from the search start point and the worker threads will process the next tile in the list. 4 threads gets a factor of 3 speedup, so not perfectly parallel but not bad. More than 4 isn't worth it. It's really for whole sky, since local searching is fast enough anyway. As you suspected, I load the whole index into memory so that each thread can read the parts it wants without competing with other threads for access to the file handle - for 40Mb that's not a problem.

I think I will have to go to Gaia not UCAC4 for the high resolution, as even at 0.5 degree UCAC4 leaves holes in some areas of the index where I get less stars than I want. Gaia looks like it requires more pre-processing of the data though to get visual magnitude estimates and to transform to J2000 + proper motion offsets for 2023/2024. UCAC4 is small enough that I can load it all into memory and process it without too much problem, but Gaia is too big for that

cheers,

Robin

[han59]

my quads are the complex sort - I set up a co-ordinate system based on the two stars that are further from each other and then (with a couple of tweaks to ensure that the hash codes are not disturbed by mirror imaging) the co-ordinates of the two remaing stars make your hash codes. Actually the slowest part is working out the 6 distances between the possible pairs of stars, so maybe just simple distances would not gain much.

Yes determining which stars form a quad is probably most CPU intensive. Something I'm still looking at.

Multi-threading is based on tiles - there are 522 tiles in the index and SharpCap will order them in distance from the search start point and the worker threads will process the next tile in the list. 4 threads gets a factor of 3 speedup, so not perfectly parallel but not bad. More than 4 isn't worth it. It's really for whole sky, since local searching is fast enough anyway. As you suspected, I load the whole index into memory so that each thread can read the parts it wants without competing with other threads for access to the file handle - for 40Mb that's not a problem.

Probably very different then my setup. In my setup a detection windows spirals in a search pattern around in the initial start point and retrieve the stars as required from one or more tiles. To speed up it keeps a cache of a tile loaded for multiple access if required.

I think I will have to go to Gaia not UCAC4 for the high resolution, as even at 0.5 degree UCAC4 leaves holes in some areas of the index where I get less stars than I want. Gaia looks like it requires more pre-processing of the data though to get visual magnitude estimates and to transform to J2000 + proper motion offsets for 2023/2024. UCAC4 is small enough that I can load it all into memory and process it without too much problem, but Gaia is too big for that

Sorting the Gaia takes for me now less then 48 hours computer processing times from start. You can extract it by parts online using Simbad but at the moment I use the original raw data and extract what I need in a few steps using a dedicated program handling .csv files. In the process I convert the positions to epoch 2025. Use the correct magnitude Bp is preferred but if a star is effect by straylight do not rely on Bp and Rp magnitudes and use the G magnitude with a correction. Same if Bp magnitude is not available. You could also calculate the V magnitude but Bp seems a better match for the typical CCD band-pass.

Han

[admin]

Hi Han,

yes, I downloaded all ~650Gb of the Gaia star position archive over the weekend, and that is compressed size. A power cut at about 90% through didn't help... I am working on narrowing down the data fields and selecting a fixed number of stars per healpix to get a uniform sample. Fortunately C# has libraries to read/write .gz files easily, so I can wrote code to directly process the compressed data rather than uncompress then process.

Thanks for the suggestions on the magnitude use - I was planning on estimating V from G and BP-RP, but I may reconsider that now.

cheers,

Robin

[admin]

Just an update...

I now have an extended index file that solves pretty well down to just below 0.25 degree FOV, based on the GaiaDR3 dataset (even using that, there are some areas where the stars are rather sparse). The larger database runs to about 160Mb, so will be an additional download. I have still to write the code to handle the download, add the options on which to use, etc.

I was pleased that when I went through the processing of the Gaia data, I ended up finding 82 bright stars missing, matching the number mentioned by Han in the description of one of his datasets

cheers,

Robin

[Jonathan Shields]

I am very impressed with this. It works very quickly even on my "vintage" laptop, solving in under 10 seconds when ASPS takes 3 minutes. Using the push to assistant or the Deep Sky Annotation Center in View feature now enables me to quickly get an object in view as long as the initial Goto has got me reasonably close.
My EAA sessions in future should now involve more viewing and less finding.
As a fellow IT pro I am very impressed with Sharpcap. Its feature rich, stable, performant on a modest device and is great value.

Thanks for your work on this.

[Borodog]

Just wanted to say that I switched from ASTAP to SharpSolve 2 nights ago and HOLY COW IS IT FAST! After switching to SharpSolve in the settings I clicked the test button an it solved in literally a fraction of a second. A SMALL fraction of a second, at that. Absolutely incredible.

Thanks for everything you do, Robin!

[admin]

Hi folks,

thanks for the positive feedback - I have to admit that the performance came out better than I had hoped... My initial goal was to get the maximum time for a whole sky search at a 1/2 degree FOV to be in the 30s to 60s on my PC (roughly how long Astap takes at 0.5 degree). I ended up with 9s, although it would be about 27s without using multiple CPU cores, which Astap doesn't currently do.

There have been a few teething problems which I am slowly ironing out, but hopefully it should achieve the main goal of making plate solving more accessible to every SharpCap user, rather than being a bit of an advanced topic due to the higher complexity of installing and configuring one of the plate solving tools.

cheers,

Robin

[admin]

Hi folks,

another update to SharpSolve today

I have updated the default plate solving index file to one generated from the Gaia catalog rather than UCAC4. Using the Gaia data helps avoid sparse areas in the index which could lead to problems with plate solving - in my testing, the catalog update alone reduced the failure rate at 0.5 by 0.5 FOV by over 60%.

I've also now got an index for solving down to 0.25 by 0.25 (actually works a bit below this, but the success rate drops rapidly between about 0.23 and 0.20 degree FOV). This new index file is about 160Mb and does not compress, so it is not included in the default install. There is a button on the plate solving settings to download it.

If you need to install the larger index on a PC with no internet access then the download is here - https://downloads.sharpcap.co.uk/psinde ... x.0.25.bin. Copy the downloaded file to the target PC and use the 'Browse for Index File...' button in the settings to select it. SharpCap will make its own private copy of the file.

Once the new index file is installed either by direct download in SharpCap or manual download and browsing for the file, the option to make SharpSolve search down to 0.25 degree FOV will become available. This makes plate solving operations about 4 times slower (four times more data to search), so it is not worth using unless you really are working at small FOV.

To go along with these updates, I have re-designed the Plate Solving settings page of the settings - see below

Screenshot 2023-11-13 120131.jpg (110.52 KiB) Viewed 40517 times

Hopefully this makes the page easier to understand and use. Key changes are

* The test button moves next to the plate solver selection drop down.
* The selection drop down shows 'not available' after the names of plate solving engines that SharpCap did not detect as being installed
* The settings for individual plate solving engines are now in tabs that you can look through at the bottom, rather than magically appearing when you selected a particular engine
* The detection results for each engine are shown in the tab alongside other settings for the engine
* Settings not related to a particular plate solving engine are grouped in a 'General' box (maybe I will rename that to 'General Plate Solving Settings'.

Hope this makes sense! Happy plate solving!

Robin

[DogWatch]

Hi Robin-

I have been using Platesolve3 with success. I'm curious as to how your new plate solving routine compares to it?

(Congratulations on your successful release of 4.1...really enjoying it!!)

Thanks,

Chuck