Problems with plate solving wide angle images
Stacking program, astrometric (plate) solver, fits file viewer
Brought to you by:
han59
Menu
▾
▴
I took a lot of tracked shots of the Perseids last week. I am trying to plate solve them - mostly to understand the error in the mount.
The frames were taken with a Canon R5 and a 40mm f/1.4 Sigma ART lens, and consist of 6 second exposures taken serially all night. The lens was wide open at f/1.4 to catch faint meteors so the stars in the corners are not perfect, but overall look reasonably good to me. I am separately processing the raw files to make the final picture - I am doing the plate solving on camera made JPEGs.
I have converted them to FIT format, and tried that. I have tried binning 2x2.
Because there is a 500Kb limit on attached files, I also made one that size. It is a crop of half of frame of the binned 2x2 version, with much more compression than I would ever normally use.
Every version of the files plate solves with Astrometry.net.
Since I want to do hours worth of tracking (i.e. thousands of frames), using Astronmetry.net isn't feasible, so I tried ASTAP.
In the past I have used ASTAP with NINA for plate solving while guiding / slewing. I have found ASTAP is great when it works, but I have little intuition as to when it will work and when it will not. It seems to be much more "fragile" than Astrometry.net in that it is very sensitive to the parameters or image.
So far, ASTAP has not worked for me for any version of the files - full res FIT, 2.2 binned FIT ... Note that ASTAP won't work even if I give it the Astometry.net solution as a starting point.
I refreshed my version ASTAP to the latest version yesterday, and use the following parameters:
Downsample 0
Max stars to use 500 (this is default, but I have tried various from 300 to 1000)
Hash code tolerance 0.007 (default, but I have tried other values)
Ignore stars less than HFD 0.8
Radius search area 180
Ignore stars sell than 2.0 (but have tried other values)
Star database used H18
I have tried this with "Slow" checked, and unchecked.
In the solver log, ASTAP typically searches for a while and then says: "Too many small quads excluded due to higher resolution database, increased the number of stars with 10%". This will repeat a number of times and then it quits without a solution.
I don't know if "higher resolution database" refers to H18, or the stars found in the image. I have increased the Max stars to use up to the max of 1000.
I am not familiar enough with ASTAP to know what to do next. So I am hoping that somebody on the forum will help.
It occurred to me that wide angle distortion could be an issue. But the 40mm sigma is only slightly wide angle (note that technically, a "normal" lens for full frame is 43 mm focal length).
It has also occurred to me that star distortion away from the center of the frame due to f/1.4 optical distortion could be an issue. I looked to see if ASTAP had a feature "only plate solve using the center of frame", but I could not find that.
Finally, the frames have airplane trails in them, and of course some have meteor trails too since that was the goal. However, there are still PLENTY of stars for plate solving.
I would be happy to post an example file, but I am new to the ASTAP forum and SourceForge so I don't know how to do that.
Nathan
Nathan,
It is no problem for me to investigate. For FOV of 33 degrees you better use the V17 (or an older G17) database. It 10 degrees larger tiles cover a larger field.
Share your images via nova.astrometry.net link or
https://ufile.io/ For multiple image, share them in a zip file.
Han
OK, great!! The original raw is here https://ufile.io/m2apobhv The FIT file I made from it using ASTAP is here https://ufile.io/huln6t51. The astrometry.net solution is
Center (RA, Dec): (276.187, 59.824)
Center (RA, hms): 18h 24m 44.762s
Center (Dec, dms): +59° 49' 25.822"
Size: 52.5 x 35 deg
Radius: 31.574 deg
Pixel scale: 23 arcsec/pixel
Orientation: Up is 57.1 degrees E of N
The link to it is http://nova.astrometry.net/user_images/5044343#annotated
The images solves using the V17 without problems. Not with the H17. But it looks better (more matches) to use a hash code tolerance of 0.01 rather then the 0.007. Not higher otherwise you get false solutions.
The focusing is not perfect and notice a donut shaped stars (central obstruction) but still good enough. So with the V17 you should be fine.
Optional. Normally you can check the solving with star annotation but it is overcrowded. But the deepsky annotation is marking the brightres stars correctly so use that for testing the solution.
Han
Try the batch solving option under tools. That should quickly solve all the images unless they are of less quality. Reasonable focus is required.
Han
Blind solving is easy. But set the search radius at 180 degrees.
Forgive the possibly dumb question but I don't see a place in ASTAP to select database. So do i delete the H18 files and install V17 instead? Or how else do I make the change?
Load an image. Go to stack menu (ctrl-A), go to tab alignment. Select there for "Star database used" V17. Hit the solve button to the save settings. You don't have to delete the H18. You can keep it for solving with Nina.
Coincidentally, I also found a bug related to the introduction of the H17, H18. Having this kind of large FOV, the first time it selects the (wrong) cropping based on the H17/H18 and not on the V17.
So it doesn't solve the first try. This is now fixed in ASTAP 0.9.570. :)
So download this version.
I have also fixed the star annotation for this large FOV. The annotation circles should match with the star. Just an other check if solving worked.
Tell me if it now works for all your images.
Han
Great, I will download the new version and try all of this and let you know...
Last edit: han.k 2021-08-20
OK, here is the situation.
The majority of the files seem to solve just fine. About 12% of them (26 out of the first 220) will not solve.
Here is a link to one of the files that failed to solve https://ufile.io/6s6plo8x
However, when I graph the plate solve results for the frames that did work, I get something strange.
Here is RA
[cid:image001.png@01D795C1.A16ED120]
Here is Dec
[cid:image002.png@01D795C1.A16ED120]
Recall that this is a long run pointed in the same direction. There should be no change in RA, Dec with perfect guiding - just a straight line. So, maybe the guiding is screwed up, or maybe plate solving has errors.
The first confusing part is that prior to about frame 1000, there is one behavior, and a second behavior afterward.
BUT, it is also the case that I changed things a bit. Up to frame 1000 the conversion to FIT was done by ASTAP, and I did 2x2 binning. While that was running, I use SIRIL to convert the frames after 1000 to FIT, with no binning. Then they were plate solved with ASTAP.
So maybe the SIRIL conversion, or maybe the lack of binning did something?
It turns out that the rate of getting a plate solve also changes a lot after frame 1000. About 29% of those did not solve.
Here is a frame (i.e. SIRIL converted and not binned) that did not solve https://ufile.io/su7uekwz
Then of the frames that did solve, some solved to a low error, "good" RA, Dec, and some had high error.
Here is a frame (i.e. SIRIL converted and not binned) that solved to a "good" RA, Dec https://ufile.io/ywe3kqr5
Here is a frame (i.e. SIRIL converted and not binned) that solved to a "bad" RA, Dec https://ufile.io/0qf4vqey
I am very interested in whether the "bad" RA,Dec values are (a) genuine, and my mount was doing the wrong thing, or (b) due to an error in plate solving, which perhaps (c) would be due to noise, clouds, or something else.
I was going to investigate this further by making binned versions in ASTAP. But I didn't realize that the USB SSD I had the data on was full. So ASTP crashed twice. I figured out that disk space was the likely issue. But now ASAP won't run at all. I rebooted the system and it still won't run.
Nathan
Last edit: han.k 2021-08-21
OK, here is the situation.
The majority of the files seem to solve just fine. About 12% of them (26 out of the first 220) will not solve.
Here is a link to one of the files that failed to solve https://ufile.io/6s6plo8x
However, when I graph the plate solve results for the frames that did work, I get something strange. Here is the RA plot
Here is the Dec plot
Recall that this is a long run pointed in the same direction. There should be no change in RA, Dec with perfect guiding – just a straight line. So, maybe the guiding is screwed up, or maybe plate solving has errors.
The first confusing part is that prior to about frame 1000, there is one behavior, and a second behavior afterward.
BUT, it is also the case that I changed things a bit. Up to frame 1000 the conversion to FIT was done by ASTAP, and I did 2x2 binning. While that was running, I use SIRIL to convert the frames after 1000 to FIT, with no binning. Then they were plate solved with ASTAP.
So maybe the SIRIL conversion, or maybe the lack of binning did something?
It turns out that the rate of getting a plate solve also changes a lot after frame 1000. About 29% of those did not solve.
Here is a frame (i.e. SIRIL converted and not binned) that did not solve https://ufile.io/su7uekwz
Then of the frames that did solve, some solved to a low error, “good” RA, Dec, and some had high error.
Here is a frame (i.e. SIRIL converted and not binned) that solved to a “good” RA, Dec https://ufile.io/ywe3kqr5
Here is a frame (i.e. SIRIL converted and not binned) that solved to a “bad” RA, Dec https://ufile.io/0qf4vqey
I am very interested in whether the “bad” RA,Dec values are (a) genuine, and my mount was doing the wrong thing, or (b) due to an error in plate solving, which perhaps (c) would be due to noise, clouds, or something else.
I was going to investigate this further by making binned versions in ASTAP. But I didn’t realize that the USB SSD I had the data on was full. So ASTP crashed twice. I figured out that disk space was the likely issue. But now ASAP won’t run at all. I rebooted the system and it still won’t run.
Nathan
ASTAP should always run. Only loading a damaged file could be a problem.
The first image _1__0018_bin2x2 solves normal.
I compared the two images. Star annotation and for the deepsky annotation the bright stars annotation matches. Also Astrometry.net comes with the same solution except some arc seconds difference. But that can problably be fixed by forcing in nova.astrometry.net reference pixel in center. See attached image.
I assume you drive is unstable?
Fro the unsolved images, probably running a local version of nova.astrometry.net via ASTAP is the solution. See tools batch menu.
Han
Last edit: han.k 2021-08-21