I am trying to debug why I have troubles with my color camera for plate solving compared to my b/w cameras. Anyway, if I start fresh with a FITs image (generated from "raw 16" format from SharpCap) and set downsample to 2 and use triples, then the image solves. When I change downsample to 0, plate solving doesn't work and it reports it is using quads instead of triples! And I can't get it to use triples by toggling the triples button again. Capture of log below:
Cheers
Graem
0:57:17 Using star database D80
0:57:17 Creating grayscale x 2 binning image for solving or star alignment.
0:57:17 22 stars, 45 triples selected in the image. 15 database stars, 31 database triples required for the square search field of 1.4°. Search window at 149% based on the number of triples. Step size at 100% of image height.
0:57:17 5 of 5 triples selected matching within 0.002 tolerance. Solution["] x:=1.218616x+ -2.070262y+ 266.079073, y:=-2.068814x+ -1.220215y+ 4469.685979
0:57:17 Solution found: 13: 21 13.4 +45° 29 02 Solved in 0.2 sec. Δ was 0.0". Used stars down to magnitude: 10.9
(And now all I did was change downsample to 0)
0:57:27 Using star database D80
0:57:28 32 stars, 25 quads selected in the image. 21 database stars, 16 database quads required for the square search field of 1.4°. Search window at 200% based on the number of quads. Step size at 100% of image height.
0:57:42 No solution found! :(
{And now I toggled "use triples" off and back on again}
0:57:49 Using star database D80
0:57:51 32 stars, 25 quads selected in the image. 21 database stars, 16 database quads required for the square search field of 1.4°. Search window at 200% based on the number of quads. Step size at 100% of image height.
0:58:04 No solution found! :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When there are about 30 stars detected your really near the minimum required. Triplets can help but is not a realible solution. To get realible solving your need more stars detected.
For colour camera it is normal beneficial to bin 2x2 the raw's unless you have low image dimensions.
First thing I would suggest is to expose longer. This should give you more stars. Better focussing also helps to detect more stars.
Can you attach one fits image so I can have a look?
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Han - I think you misunderstood the point of my post. I am reporting that the "use triples" button quit functioning when I did the above mentioned steps. Notice that the log states it started using quads instead of triples even though I never unchecked the "use triples" button.
Thanks for the quick responses!
Graem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay missed that. Triples are disabled automatically as soon there are 30 stars or more detected. The reason is that the number of triples increases very fast with the number of stars detected. The 30 is arbitrary. Could also be 35. Honestly I lost interest in triples some time ago. It is not a magic silver bullet. It helps solving images with a few stars. But a few stars detected is rare. I'm still considering to remove it to clean up and simplify the code. How does it perform in practise?
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was practising different settings with ASTAP last night to try and understand how it works. I was using a stationary finder scope so I could not set too long an exposure without creating star trails. I found that downsampling=2 and using triples worked the best. Note that I was using SharpCap to generate a FITs image and manually calling ASTAP.
The reason I have been debugging is actually because I was getting too many stars reported (over 500) when using SharpCap to plate solve with ASTAP (and it always failed). I assumed this was a bug with SharpCap and have reported it on SharpCaps forum. But it may be a bug with ASTAP. Here is a link to the report:
I am not sure this will be useful, but I took a couple captures with the lens cap on (it is cloudy outside so I can't take star pictures). These images will generated by SharpCap (one is .PNG that was generated for ASTAP to platesolve, and one is .FITS that was manually saved). When platesolved with ASTAP (no binning used), ASTAP says there is 652 stars in the .PNG and only 72 stars in the .FITS. I understand these captures are just noise, but why would one be a magnitude greater in fake stars. I think answering this question would answer my issue noted in the SharpCap bug report mentioned above.
Thanks
Graem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only thing my untrained eye sees different between the two files is that hot pixels in the .FITS file are one pixel wide whereas hot pixels in the .PNG file seem to have bled across multiple pixels.
Graem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
so I'm afraid that almost of the star like pixels are just noise/hotpixels. Normally nova.astrometry.net is better in solving these images then ASTAP. Note that triples could easier result in false solving.
I suggest you increase the exposure time from 0.5 to maybe 5 or 10 seconds or even higher. That should work with short focal distances.
You could also instruct ASTAP to subtract a dark prior to solving. Select option "calibrate prior to solving"in tab alignment. Then add one or more darks to tab dark. That will also help to eliminate hot pixels and noise.
Attach an image of longer exposure and I will look again
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Han - I am not sure why you tried to solve the FITs file in nova.astrometry.net. I took those pictures "with the lens cap on". I think I have just proved why my colour camera is not working with SharpCap feeding a PNG file to ASTAP. SharpCap appears to be bleeding hot pixels into the surrounding pixels (with PNG files) and this results in ASTAP getting confused on what are stars and what are hot/high random noise pixels. I repeated this test with my B/W camera and the PNG file does not show this bleeding of hot pixels. This would explain why my colour camera doesn't work at plate solving but my B/W cameras do. I was using AstroimageJ to view the files and I assume it is not doing anything funny with the pixels.
I will bring this issue up with the author of SharpCap. I have included the corresponding B/W camera images (ASI432MM) so you can see that hot pixels do not bleed in the PNG file.
Sorry. I'm busy with several things at the same time and missed your lens cap.
I managed to compare the fits with the PNG. The png you need to physically swap vertical to compare. (tools, rotate image) Pixel 271,1988 in the fits can then be found in the PNG. Looks a jpeg converted to png. Note the pixel value is also reduced in value. Not good
for solving. Show attached attachment to Robin.
Does ASTAP require or prefer a debayered image for platesolving? I'm thinking it might just prefer a 2x2 binning of a non-bayered image which effectively turns it into a mono image?
Thanks
Graem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In any case debayering is not good. It reduces the resolution/sharpness. If the resolution allows (>2000x2000 pixels) just binning 2x2 is best else keep it raw.
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Han: Just letting you know that Robin has released a beta version of SharpCap that passes raw FITs to ASTAP. The following is testing information I posted on the SharpCap forum:
Hi Robin - I did some quick testing of ASTAP plate solving with SharpCap 4.0.9538 64bit vs SharpCap 4.1.10745 64 bit. I'm still using the ASI178MC camera with a finder scope of focal length of 222mm. Exposure set to 1.9 seconds.
Using the old version of SharpCap and no binning, ASTAP would report about 400 stars and would always fail plate solving. If I used the "-z 2" option, ASTAP would report about 90 stars and would solve about 3/4 of the time.
Using the new version of SharpCap and no binning, ASTAP would report about 50 stars and solve about half of the time. If I used the "-z 2" option, ASTAP would again report about 50 stars and would solve all of the time.
So in conclusion, the new version of SharpCap cuts down the number of fake stars that ASTAP reports. I still need to use binning to get the best ASTAP performance. I assume that 2x2 binning is almost like converting a bayer matrix to mono (since the 2 green, 1 blue and 1 red pixels are getting converted into 1 pixel?).
Graem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to debug why I have troubles with my color camera for plate solving compared to my b/w cameras. Anyway, if I start fresh with a FITs image (generated from "raw 16" format from SharpCap) and set downsample to 2 and use triples, then the image solves. When I change downsample to 0, plate solving doesn't work and it reports it is using quads instead of triples! And I can't get it to use triples by toggling the triples button again. Capture of log below:
Cheers
Graem
0:57:17 Using star database D80
0:57:17 Creating grayscale x 2 binning image for solving or star alignment.
0:57:17 22 stars, 45 triples selected in the image. 15 database stars, 31 database triples required for the square search field of 1.4°. Search window at 149% based on the number of triples. Step size at 100% of image height.
0:57:17 5 of 5 triples selected matching within 0.002 tolerance. Solution["] x:=1.218616x+ -2.070262y+ 266.079073, y:=-2.068814x+ -1.220215y+ 4469.685979
0:57:17 Solution found: 13: 21 13.4 +45° 29 02 Solved in 0.2 sec. Δ was 0.0". Used stars down to magnitude: 10.9
(And now all I did was change downsample to 0)
0:57:27 Using star database D80
0:57:28 32 stars, 25 quads selected in the image. 21 database stars, 16 database quads required for the square search field of 1.4°. Search window at 200% based on the number of quads. Step size at 100% of image height.
0:57:42 No solution found! :(
{And now I toggled "use triples" off and back on again}
0:57:49 Using star database D80
0:57:51 32 stars, 25 quads selected in the image. 21 database stars, 16 database quads required for the square search field of 1.4°. Search window at 200% based on the number of quads. Step size at 100% of image height.
0:58:04 No solution found! :(
When there are about 30 stars detected your really near the minimum required. Triplets can help but is not a realible solution. To get realible solving your need more stars detected.
For colour camera it is normal beneficial to bin 2x2 the raw's unless you have low image dimensions.
First thing I would suggest is to expose longer. This should give you more stars. Better focussing also helps to detect more stars.
Can you attach one fits image so I can have a look?
Han
Hi Han - I think you misunderstood the point of my post. I am reporting that the "use triples" button quit functioning when I did the above mentioned steps. Notice that the log states it started using quads instead of triples even though I never unchecked the "use triples" button.
Thanks for the quick responses!
Graem
Forgot to mention: Using windows10, ASTAP2023.05.09, 64bit with D80 database
Graem
Okay missed that. Triples are disabled automatically as soon there are 30 stars or more detected. The reason is that the number of triples increases very fast with the number of stars detected. The 30 is arbitrary. Could also be 35. Honestly I lost interest in triples some time ago. It is not a magic silver bullet. It helps solving images with a few stars. But a few stars detected is rare. I'm still considering to remove it to clean up and simplify the code. How does it perform in practise?
Han
I was practising different settings with ASTAP last night to try and understand how it works. I was using a stationary finder scope so I could not set too long an exposure without creating star trails. I found that downsampling=2 and using triples worked the best. Note that I was using SharpCap to generate a FITs image and manually calling ASTAP.
The reason I have been debugging is actually because I was getting too many stars reported (over 500) when using SharpCap to plate solve with ASTAP (and it always failed). I assumed this was a bug with SharpCap and have reported it on SharpCaps forum. But it may be a bug with ASTAP. Here is a link to the report:
https://forums.sharpcap.co.uk/viewtopic.php?t=6616
Graem
I am not sure this will be useful, but I took a couple captures with the lens cap on (it is cloudy outside so I can't take star pictures). These images will generated by SharpCap (one is .PNG that was generated for ASTAP to platesolve, and one is .FITS that was manually saved). When platesolved with ASTAP (no binning used), ASTAP says there is 652 stars in the .PNG and only 72 stars in the .FITS. I understand these captures are just noise, but why would one be a magnitude greater in fake stars. I think answering this question would answer my issue noted in the SharpCap bug report mentioned above.
Thanks
Graem
The only thing my untrained eye sees different between the two files is that hot pixels in the .FITS file are one pixel wide whereas hot pixels in the .PNG file seem to have bled across multiple pixels.
Graem
The PNG is 16 bit but it is difficult to say if it is different.
The FITS file fails to solve in nova.astrometry.net:
https://nova.astrometry.net/status/7796819
so I'm afraid that almost of the star like pixels are just noise/hotpixels. Normally nova.astrometry.net is better in solving these images then ASTAP. Note that triples could easier result in false solving.
I suggest you increase the exposure time from 0.5 to maybe 5 or 10 seconds or even higher. That should work with short focal distances.
You could also instruct ASTAP to subtract a dark prior to solving. Select option "calibrate prior to solving"in tab alignment. Then add one or more darks to tab dark. That will also help to eliminate hot pixels and noise.
Attach an image of longer exposure and I will look again
Han
The images look different, but yes the PNG looks smoothed. There could be a flip involved. When there is a solve is is better to see any difference.
Hi Han - I am not sure why you tried to solve the FITs file in nova.astrometry.net. I took those pictures "with the lens cap on". I think I have just proved why my colour camera is not working with SharpCap feeding a PNG file to ASTAP. SharpCap appears to be bleeding hot pixels into the surrounding pixels (with PNG files) and this results in ASTAP getting confused on what are stars and what are hot/high random noise pixels. I repeated this test with my B/W camera and the PNG file does not show this bleeding of hot pixels. This would explain why my colour camera doesn't work at plate solving but my B/W cameras do. I was using AstroimageJ to view the files and I assume it is not doing anything funny with the pixels.
I will bring this issue up with the author of SharpCap. I have included the corresponding B/W camera images (ASI432MM) so you can see that hot pixels do not bleed in the PNG file.
Graem
Sorry. I'm busy with several things at the same time and missed your lens cap.
I managed to compare the fits with the PNG. The png you need to physically swap vertical to compare. (tools, rotate image) Pixel 271,1988 in the fits can then be found in the PNG. Looks a jpeg converted to png. Note the pixel value is also reduced in value. Not good
for solving. Show attached attachment to Robin.
Cheers, Han
Last edit: han.k 2023-05-29
I passed the info to Robin.
Does ASTAP require or prefer a debayered image for platesolving? I'm thinking it might just prefer a 2x2 binning of a non-bayered image which effectively turns it into a mono image?
Thanks
Graem
In any case debayering is not good. It reduces the resolution/sharpness. If the resolution allows (>2000x2000 pixels) just binning 2x2 is best else keep it raw.
Han
Hi Han: Just letting you know that Robin has released a beta version of SharpCap that passes raw FITs to ASTAP. The following is testing information I posted on the SharpCap forum:
Hi Robin - I did some quick testing of ASTAP plate solving with SharpCap 4.0.9538 64bit vs SharpCap 4.1.10745 64 bit. I'm still using the ASI178MC camera with a finder scope of focal length of 222mm. Exposure set to 1.9 seconds.
Using the old version of SharpCap and no binning, ASTAP would report about 400 stars and would always fail plate solving. If I used the "-z 2" option, ASTAP would report about 90 stars and would solve about 3/4 of the time.
Using the new version of SharpCap and no binning, ASTAP would report about 50 stars and solve about half of the time. If I used the "-z 2" option, ASTAP would again report about 50 stars and would solve all of the time.
So in conclusion, the new version of SharpCap cuts down the number of fake stars that ASTAP reports. I still need to use binning to get the best ASTAP performance. I assume that 2x2 binning is almost like converting a bayer matrix to mono (since the 2 green, 1 blue and 1 red pixels are getting converted into 1 pixel?).
Graem
Thanks for the info.
Yes binning 2x2 is like making mono.
I posted at the SharpCap forum:
https://forums.sharpcap.co.uk/viewtopic.php?p=36560#p36560
Han