Alternative Plate Solver

Anything that doesn't fit into any of the other forums
User avatar
admin
Site Admin
Posts: 4770
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Alternative Plate Solver

Post by admin » Sun Apr 05, 2020 7:06 pm

Hi,

Have you adjusted the exposure or gain of the test camera away from the default values? If you do that then SharpCap scales the brightness of the image appropriately – so if the image started out having a full range of values but you've reduced the exposure from 1 second to 10 ms, then the image on screen and the one that is captured and sent to the plate solving application will be mostly zeros and ones with the occasional two. In real usage the image will have a full range of values and will be either 8 bit or 16 bit PNG depending on the camera configuration.

One quick question for you – I thought based on your earlier answers that if you run the solver with the '-fov 0' parameter then it would work out the field-of-view and store that field of view for future runs that do not specify the field-of-view – as far as I can see that doesn't happen in my testing. Did I missinterpret how it should work perhaps?

Cheers, Robin

han59
Posts: 15
Joined: Wed Apr 01, 2020 11:02 am

Re: Alternative Plate Solver

Post by han59 » Tue Apr 07, 2020 6:51 pm

Hello Robin,

For the camera, I'm using an ASCOM simulator variant called Sky simulator for ASCOM. There is no setting for gain. The test image (from file) brightness and contrast are independent of the exposure time. If you have no problem with a real camera then there is no problem. I will try to test SharpCap tonight with a real camera.

>>One quick question for you – I thought based on your earlier answers that if you run the solver with the '-fov 0' parameter then it would
>> work out the field-of-view and store that field of view for future runs that do not specify the field-of-view – as far as I can see that
>> doesn't happen in my testing.

Your correct. it doesn't work in the command line. I works in the graphical user interface (if you hit the solve button for the second time), so I wrongly assumed it would also work in the command line. I will fix that tonight in ASTAP version 0.9.340.

Regards, Han

han59
Posts: 15
Joined: Wed Apr 01, 2020 11:02 am

Re: Alternative Plate Solver

Post by han59 » Tue Apr 07, 2020 9:04 pm

ASTAP 0.9.340 with a working command line FOV learn mode is now issued:

So first time add to the command line: -fov 0
After a successful solve ASTAP will remember the found fov and specifying the fov in the command line is no longer required.

P.s. checklist for successful solving with ASTAP:

- At least 30 stars are visible
- Reasonable round stars
- Image dimensions at least 1500 x 1000 pixels
- Image is not stretched or heavily photo shopped.
- Correct image height in degrees specified within 10% accuracy. (or auto fov is applied)

Regards Han

han59
Posts: 15
Joined: Wed Apr 01, 2020 11:02 am

Re: Alternative Plate Solver

Post by han59 » Wed Apr 08, 2020 10:05 am

This morning during daytime I had some time to play with Sharpcap connected to my ASI1600.

The image to solve "frame.png" is unfortunately a 3x8 bit per pixel PNG file. So the 16 bit images from the 12 bit camera are finally reduced to 8 bit/ pixel. This will reduce the rate of success for solving. Faint stars will fade away and ASTAP is less capable of separating bright from faint stars. If behaves different the Astrometry.net. Astrometry.net can solve image of only 1 bitpixel. ASTAP can't.

So I would suggest to change the "frame.png" to a 16 bit/pixel similar as the other files I see in the Temp directory e.g. tmp3BE3.tmp.png

About my previous problem using the ASCOM simulator (Sky simulator for ASCOM), default I can set it in Sharpcap the camera only at mono16. There is no mono8 available. However if I change in the ASCOM camera simulator the range from 0..65535 to 0..255 suddenly the MONO8 option is shown in Sharpcap and I can download recognisable images from the camera simulator :) This illustrates that reducing 16 bit images to 8 bit is not ideal. An image with data range 0..255 transported in 16 bit will be reduced to nothing if reduced to 8 bit. So 16 bit png please. :)


With the Sky simulator for ASCOM running an other problem occurred. The image taking and solving goes all well. Only the position data imported looks totally wrong:
sharpcap1.png
sharpcap1.png (7.66 KiB) Viewed 804 times
It always shows RA and DEC offsets in the max integer range. Note the found solution is written both to an .ini and .wcs file. Both files give the same solved position as follows:

CRVAL1 = 3.954367528359E-002 / RA of reference pixel (deg)
CRVAL2 = 3.466241241475E-002 / DEC of reference pixel (deg)

The reference pixel is always the middle of the image so no additional conversion required.

Regards, Han

User avatar
admin
Site Admin
Posts: 4770
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Alternative Plate Solver

Post by admin » Wed Apr 08, 2020 4:25 pm

Hi Han,

I will look into the bit depth issue again and come back to you with an update.

Can you send me the WCS and log file that results in the bad coordinates being displayed? I will test it against my reading code here to see if I can work out what is going wrong. I get the RA and declination by parsing the CRVAL1/CRVAL2 values out of the WCS file. I wonder if it might be something to do with decimal separator characters if your computer is set up to use something other than a '.' character?

Cheers, Robin

han59
Posts: 15
Joined: Wed Apr 01, 2020 11:02 am

Re: Alternative Plate Solver

Post by han59 » Wed Apr 08, 2020 7:22 pm

Hello Robin,

Yes setting the regional separator from comma to dot in Windows fixes the problem. Don't expect any comma in the attached .ini and .wcs files. The FITS standard specifies always a dot decimal separator and since .wcs is a FITS header, I follow the FITS standard. Astrometry.net does the same writing a .wcs file.

The auto learn feature for finding the image FOV works very smooth with ASTAP 0.9.340. So if no solution is found SharpCap executes the auto FOV mode using -fov 0

So all good. Just expect always a dot decimal separator and write a 16 bit/pixel png file and it will work very smooth. :)

Regards, Han
Attachments
frame files.zip
(1.81 KiB) Downloaded 24 times

han59
Posts: 15
Joined: Wed Apr 01, 2020 11:02 am

Re: Alternative Plate Solver

Post by han59 » Sat Apr 18, 2020 8:22 am

Hello Robin,

Just curious, when can we expect a new SharpCap version?

Cheers, Han

User avatar
admin
Site Admin
Posts: 4770
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Alternative Plate Solver

Post by admin » Sat Apr 18, 2020 8:39 am

Hi Han,

This weekend – I did put up a new version earlier in the week but had to take it down again due to a newly introduced bug that I haven't spotted in testing.

Cheers, Robin

han59
Posts: 15
Joined: Wed Apr 01, 2020 11:02 am

Re: Alternative Plate Solver

Post by han59 » Sat Apr 18, 2020 3:08 pm

Robin,

Looks good. The two outstanding issues, decimal separator and 16 bit png exchange format are all solved! :)

Han

han59
Posts: 15
Joined: Wed Apr 01, 2020 11:02 am

Re: Alternative Plate Solver

Post by han59 » Wed Apr 22, 2020 8:37 am

Hello Robin,

The current ASTAP auto find of FOV goes from 9.5 degrees down to 0.6 degrees image height. One SharpCap user reports at CloudyNights a system which produces images of size 0.42 x 0.28 degrees. The auto FOV will not work and requires a manually setting in ASTAP manually. After that is good to go.

In ASTAP I could increase the search range from 9.5 down to 0.3 degrees image height. Before I do that can your confirm there a several SharpCap users with a small image size like his? I assume you have better overview of the users equipment then me.

Cheers, Han

Later
For the moment I added one more step in the code and ASTAP will lock on images with an image height roughly between 11.9 down to 0.3 degrees. The only problem I see in case of a very poor quality image it takes much longer to report "not solvable".

Post Reply