Persistent incorrect field of view setting
Stacking program, astrometric (plate) solver, fits file viewer
Brought to you by:
han59
Menu
▾
▴
my ASTAP version 20260730 has a tendency to overwrite my correct field of view setting 0.27 deg with 0.28 which results in falure to solve my frames. FITS headers in all my files show correct focal length 670 mm, pixels size 1.45 and pixel count 2160. This computes to 0.268, rounded up to 0.27. When I manually enter 0.27 the plates solves efortlessly, but as it does the setting immediately reverts to 0.28, preventing it from solving the next frame (or the same frame). Interestingly enough, the pixel2math tab also has incorrect focal length of 645, where the incorrect field of view comes from. I do not know where did 645 mm come from. NINA setting is 670. This must be an artefact from some time ago when I indeed have 650 mm mirror, but I cant figure out how to change it. The problem exists in both ASTAP installations I have, one on my scope mini PC where I have NINA installed along with ASTAP, and on my office PC where I do not have NINA or any other imaging software. I have tried running both D20 and D50 databases, and when I first switched to D50 it seemed to help for a while, but not for long. After a few frames it still reverted to 0.28. I have checked and in astap.cfg the value is correct: 0.27. I am at a loss where does ASTAP get this worng frame size and how to fix it. Any suggestions would be greatly appreciated. One more fact, when astap is called through NINA interface, it seems to work fine. NINA is probably passing correct value. But when launched on its own for image processing, it seems to pull that value from some place else. It does not come from FITS headers and not from .cfg file. So where does it come from?
Hi,
A change of 0.27 to 0.28 should not make a difference in solving. The tolerance for wrong setting is about 20% to 30%, and for star rich images up to 40%.
The FOV value measured is very accurate and based on the star database positions. I assume the pixel size should also be very accurate. The only value which is not very accurate is the focal length. Most users report a different focal length then what is documented. A telescope's stated focal length is often inaccurate in practice because changing the distance between lenses or mirrors (back focus) shifts the actual focal point. But again it should not influence the solving.
Can you share an image where you think solving is hampered by the focal length?
cs, Han
I suspect your solving problem is caused by something else. Maybe hot pixels. Share an image and I will have a look.
One correction, the measured FOV could be off due to optical distortion so it is also not perfect.
Thank you for responding so quickly.
here is the image example, this one solves with 0.27 FOV and does not solve with 0.28. I have used D50 database. Stars less than 1.5 were ignored, other settings are all default. https://drive.google.com/file/d/18CW6264xeJ6VF-w05ygWo-C7EMDtAMTo/view?usp=sharing
I completely agree, for most images FOV is not critical, ASTAP solves 99% of my images without any problems. I am very much impressed with the speed and accuracy. In this run however, about a half of shots were unsolvable, but many could be solved with changed 0.27 FOV. It was a bad run, the target is difficult, with all these dust clouds blocking the stars, and exposure is too short. I am not complaining about ASTAP not being able to solve this at all. Failing to solve such an empty plate is completely understandable.
What I am trying to understand is how can I make my settings changes to stick and not be altered automatically for unknown reason. Or at least understand where does this change come from.
As for the focal length you are absolutely correct, my scope 130DX made by celestron, it was as cheap as they come. I am sure the mirror was never measured at the factory, they just say it is 650 mm and for a long time I used 650 mm in all settings and everything was fine. That is until I decided to image C4. This is where I have discovered that the real focal length is 670. I do not have any filters or lenses so it is just a mirror manufacturing tolerance. I have adjusted NINA settings, and now it makes accurate headers. But there must be some setting somewhere I have overlooked that still set to 650. I wonder where it is.
Best regards
Max
as to your point about distortion. This makes sense. If the telescope manufacturer states that focal length is 650 while it is in fact 670, then how can we trust their statement that the mirror is parabolic. It could easily be spherical. Or somewhere in between. If this is the case then I can see how calculated FOV could be off.
But still, if I could make ASTAP to prioritize FITS file numbers when solving, some frames could be saved. This is especially important when centering on a difficult target. In post processing I can always adjust the setting, but during a session it is hard to do
I think I have found a workaround for this. If I force x2 binning the plate solves with incorrect 0.28 FOV. Here is the log from three solves, first with 0.27 - solved, second with 0.28-fails. In both cases downsampling was set to 0 and ASTAP decided to bin x3. The last solve was with downsamplig set to 2, and it solved with 0.28 FOV
8:18:55 AM Creating grayscale x 3 binning image for solving or star alignment.
8:18:55 AM 44 stars, 131 quads selected in the image. 80 database stars, 237 database quads required for the 0.48° square search window. Step size 0.27°. Oversize 1.78
8:18:55 AM 4 of 4 quads selected matching within 0.007 tolerance. Solution["] x:=-0.273043x+ 0.371837y+ 122.882774, y:=0.371011x+ 0.273414y+ -1007.631897
8:18:55 AM Solution found: 21: 01 41.83 +68° 08 57.7 Solved in 0.1 sec. Δ was 0.4". Mount Δα=-1.0', Δδ=3.3'. Used stars down to magnitude: 16.0
8:58:00 AM Using star database D50
8:58:00 AM Creating grayscale x 3 binning image for solving or star alignment.
8:58:00 AM 44 stars, 131 quads selected in the image. 80 database stars, 237 database quads required for the 0.50° square search window. Step size 0.28°. Oversize 1.78
8:58:01 AM No solution found! :(
8:58:06 AM Using star database D50
8:58:06 AM Creating grayscale x 2 binning image for solving or star alignment.
8:58:06 AM 35 stars, 101 quads selected in the image. 80 database stars, 231 database quads required for the 0.56° square search window. Step size 0.28°. Oversize 2.00
8:58:06 AM 8 of 8 quads selected matching within 0.007 tolerance. Solution["] x:=-0.272938x+ 0.371833y+ 122.632000, y:=0.371013x+ 0.272187y+ -1006.018356
8:58:06 AM Solution found: 21: 01 41.81 +68° 08 57.3 Solved in 0.1 sec. Δ was 0.7". Mount Δα=-1.0', Δδ=3.3'. Used stars down to magnitude: 15.5
Hi Maxim,
I see the same here. The forced binning at 2 works better then the automatic selected 3.
The solving works more reliable if you select a smaller FOV then it in reality. I can see that some hot pixels are seen as as stars. Then ASTAP extracts more database stars to compare and the match is worse. You can compensate that by selecting a smaller FOV (set a longer focal length in Nina). Then less star databases are selected and the the amount of real stars detected in the image and database match better and the quads made of stars match then also better.
Filtering by "ignoring stars less then size .." does not help. It detects pairs of hotpixels. So the only things you can do is:
1) setting a fixed binning of 2
2) A slightly reduced FOV setting (by setting focal length longer then it is) Ignore the warning.
3) Use a camera with less hot pixels or a cooled camera.
So 1) and 2) for the moment.
cs, Han
yes, thank you. all this makes sense. cooled camera is definetely on my list of things to buy
I did try setting smaller field of view but I found that reducing it below 0.27 also makes it worse. So I think I will leave it 0.27 and set downsampling to 2.
Thanks again for helping me with this