I am facing problems when solving images from global cluster. My idea was to study the (faint) variable stars there. Thus I am taking frames of 30 seconds and make frame merging (9 x 30 =270s) to avoid saturation. Some months ago I tried with a DSLM camera (Nikon Z50), noticed solving problems and though this might be a problem of using a DSLM. Now I have an astrocamera (ZWO ASI585MC Air) but I am facing the same solving problem.
I tried also other objects: open clusters, galaxies, even with heavy stray light and ASTAP had no problems with solving. Only globular clusters seem to be problematic, and yes, I noticed that this was reported earlier. But even in the version 2026-03-05 it is still a problem.
For photometry I used Phoranso, using the ASTAP solver. In cases where solving often fails I made a first run directly in ASTAP, identifying (summary)frames that do not work. In some cases I was able to solve some of them after flipping or rotation.
My present object was M3. In the alignment Tab I activated “slow”, downsample 0 and used star database V05. First I used Gain 0 and with using the option “slow” I was able to solve 23 of 29 frames - acceptable. With flipping and rotation I was able to raise the number of usable frames to 28 (one frame remained unsolvable despite all modifications). With Gain200 (to get better SNR for my variables) it was even worse: only 30 frames of 65 have been solved = scrap rate 54%.
Now I tried the following:
V50 star database, downsample 0: 29 of 65
Increase stars (500 -> 1000): same (29 of 65, = no effect)
D80 star database, 500 stars maximum: this raised the usable frame to 46 of 65. But still a scrap rate of 29%.
In subsequent runs with V05 star database the number of usable frames kept its value of 46, but if I use a new copy of my photometry series I came back to only 30 solved frames.
When deactivating “skip image solving if solving info is present in image” the solved frames raised to 50 (D80 used) with a new copy of the frames (but still 23% scrap rate).
For variables in global clusters every frame counts, thus a scrap rate of over 10% is not acceptable.
I would greatly appreciate a special option for globular clusters within the alignment tab using a better algorithm for solving them (and without the necessity to flip and rotate myself).
One idea might be an “avoidance” of the cluster core itself: identifying the cluster and using only stars in the less dense area for solving.
Best whises
Jörg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes this is an old problem. The high density of stars in the cluster confuses the solver. A larger field-of-view helps but you can't change your system without changing the telescope or camera.
I quick fix for measuring the variables would be to solve the images in an other solver like Astrometry.net. You can do that batch wise in ASTAP if you have a local Astrometry.net installed. ASTAP will accept the Astrometry.net solution in the FITS header and you can do photometry.
I have no problem to look again into this old problem. Can you share some of the failed M3 images so I can experiment with them?
cs, Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Han,
I am facing problems when solving images from global cluster. My idea was to study the (faint) variable stars there. Thus I am taking frames of 30 seconds and make frame merging (9 x 30 =270s) to avoid saturation. Some months ago I tried with a DSLM camera (Nikon Z50), noticed solving problems and though this might be a problem of using a DSLM. Now I have an astrocamera (ZWO ASI585MC Air) but I am facing the same solving problem.
I tried also other objects: open clusters, galaxies, even with heavy stray light and ASTAP had no problems with solving. Only globular clusters seem to be problematic, and yes, I noticed that this was reported earlier. But even in the version 2026-03-05 it is still a problem.
For photometry I used Phoranso, using the ASTAP solver. In cases where solving often fails I made a first run directly in ASTAP, identifying (summary)frames that do not work. In some cases I was able to solve some of them after flipping or rotation.
My present object was M3. In the alignment Tab I activated “slow”, downsample 0 and used star database V05. First I used Gain 0 and with using the option “slow” I was able to solve 23 of 29 frames - acceptable. With flipping and rotation I was able to raise the number of usable frames to 28 (one frame remained unsolvable despite all modifications). With Gain200 (to get better SNR for my variables) it was even worse: only 30 frames of 65 have been solved = scrap rate 54%.
Now I tried the following:
V50 star database, downsample 0: 29 of 65
Increase stars (500 -> 1000): same (29 of 65, = no effect)
D80 star database, 500 stars maximum: this raised the usable frame to 46 of 65. But still a scrap rate of 29%.
In subsequent runs with V05 star database the number of usable frames kept its value of 46, but if I use a new copy of my photometry series I came back to only 30 solved frames.
When deactivating “skip image solving if solving info is present in image” the solved frames raised to 50 (D80 used) with a new copy of the frames (but still 23% scrap rate).
For variables in global clusters every frame counts, thus a scrap rate of over 10% is not acceptable.
I would greatly appreciate a special option for globular clusters within the alignment tab using a better algorithm for solving them (and without the necessity to flip and rotate myself).
One idea might be an “avoidance” of the cluster core itself: identifying the cluster and using only stars in the less dense area for solving.
Best whises
Jörg
Ho Joerg,
Yes this is an old problem. The high density of stars in the cluster confuses the solver. A larger field-of-view helps but you can't change your system without changing the telescope or camera.
I quick fix for measuring the variables would be to solve the images in an other solver like Astrometry.net. You can do that batch wise in ASTAP if you have a local Astrometry.net installed. ASTAP will accept the Astrometry.net solution in the FITS header and you can do photometry.
I have no problem to look again into this old problem. Can you share some of the failed M3 images so I can experiment with them?
cs, Han