Thank you for ASTAP. We use astap_cli in an open-source observatory-control project, and our nightly test caught a regression in CLI-2026.10.30, which we then bisected with builds from your repository. We see it on Linux x64, Linux arm64, macOS M1 and Windows x64.
Test frame (2 MB, 1024×1024 crop of an FSQ106 + QHY600M frame of M101, pointing keywords removed): m101_known.fits (github.com). Database: D05 (d05_star_database.zip, unchanged since 2026-05).
-threads 1 gives byte-identical output, so the parallel search itself does not seem to be the cause.
With -progress -log, the first pass at the start position finds the field with 5 references, and the second pass finds only 1 and drops it (2026.09.01 finds 8, then 4). After that the spiral continues and finds nothing:
Search 0, [0,0], position: 14: 03 14.4+54d 20 49 Down to magn 17.6 140 database stars 105 database quads to compare.
Found 5 references
Search 0, [0,0], position: 14: 03 14.4+54d 20 49 Down to magn 18.3 99 database stars 74 database quads to compare.
Found 1 references
A blind solve (-r 180, FOV 0.42 from the header) behaves the same way. The first pass finds the field about 125° from the 0,0 start, which is where M101 is. The second pass then spirals from there out to 180° without a match. Single-threaded that takes 117 s, where 2026.09.01 solved it blind in about 48 s.
-fov 0 (auto) does solve, at the 0.56° trial with 157 stars (correct centre, Δ 0.1"), then warns "scale was inaccurate! Set FOV=0.42d". So the failure seems to show up when the star budget is tight, at the correct FOV.
-t 0.010, -speed slow and -s 1000 make no difference.
We then built astap_cli from your Mercurial repository to bisect it, with Free Pascal 3.2.3 and fpc -MObjFPC -Scghi -O1 -XX -Si astap_command_line.lpr. Our builds of 97a3110d0305 and 2e83d86b41fe reproduce the output of your 2026.09.01 and 2026.10.30 binaries exactly.
Every 2026.09.xx revision solves the frame, up to 535d7d43270c (v2026.09.19). 2e83d86b41fe, the build you released, fails, and so does the tip, 26e92ce7882c. The two v2026.10.29 commits don't compile as committed (unit_ricecomp_unthreaded is missing), so we could not narrow it further by revision.
The database side is identical in every build: 140 stars and 105 quads in the first pass, 99 and 74 in the second. The image side differs: 89 stars in 2026.09.01, 88 in 2026.10.30.
On this frame, find_stars needs its last retry, the raster pass, to reach the 88 stars requested:
Reverting only the star detection in find_stars on 2e83d86b41fe makes it solve, with output identical to 2026.09.01: 89 stars, 68 quads, Found 8 then 4 references, solved in 0.1 s, and the same CRVAL1 and CRVAL2 to every digit. The revert puts back the 4-pixel cross with at least 2 neighbours, 4σ instead of 6σ on the first try, and 7σ, 4σ and SNR 10 instead of 5.5σ, 2.2σ and SNR 7 in the raster pass. Either half alone does not solve it, and disabling clip_and_refit and the skew check changes nothing.
The revert, against 2e83d86b41fe:
--- a/command-line_version/unit_command_line_solving.pas+++ b/command-line_version/unit_command_line_solving.pas@@ -1301,13 +1301,9 @@ if rowC[fitsX-1]>level_star2 then inc(starpixels);//= if img[0,fitsY,fitsX-1]- backgr>detection_level_around then inc(starpixels);
if rowC[fitsX+1]>level_star2 then inc(starpixels);//= if img[0,fitsY,fitsX+1]- backgr>detection_level_around then inc(starpixels);
if rowM[fitsX] >level_star2 then inc(starpixels);//= if img[0,fitsY-1,fitsX]- backgr>detection_level_around then inc(starpixels);
- if rowM[fitsX-1]>level_star2 then inc(starpixels);//= if img[0,fitsY-1,fitsX-1]- backgr>detection_level_around then inc(starpixels);- if rowM[fitsX+1]>level_star2 then inc(starpixels);//= if img[0,fitsY-1,fitsX+1]- backgr>detection_level_around then inc(starpixels); if rowP[fitsX] >level_star2 then inc(starpixels);//= if img[0,fitsY+1,fitsX]- backgr>detection_level_around then inc(starpixels);
- if rowP[fitsX-1]>level_star2 then inc(starpixels);//= if img[0,fitsY+1,fitsX-1]- backgr>detection_level_around then inc(starpixels);- if rowP[fitsX+1]>level_star2 then inc(starpixels);//= if img[0,fitsY+1,fitsX+1]- backgr>detection_level_around then inc(starpixels);- if starpixels>=3 then //At least 1+3 illuminated pixels. Not a hot pixel+ if starpixels>=2 then //At least 1+2 illuminated pixels. Not a hot pixel begin
HFD(img,fitsX,fitsY,14{annulus radius}, hfd1,star_fwhm,snr,flux,xc,yc);{star HFD and FWHM}
if ((hfd1<=30) and (snr>snr_minimum) and (hfd1>hfd_min) {0.8 is two pixels minimum} and (img_sa[0,round(yc),round(xc)]<>retries)) then
@@ -1385,7 +1381,7 @@ if head.star_level >30*noise_level then
begin
detection_level:=head.star_level;
- detection_level_around:=6*noise_level;+ detection_level_around:=4*noise_level; find_stars_routine(1,width2-1-1,1,height2-1-1);
end
else
@@ -1410,7 +1406,7 @@ end;
if retries=1 then //last try to find faint stars, divide image in sections and for each section find background and noise level
begin
- snr_minimum:=7;//reduce from 10 to 7+ snr_minimum:=10; if height2<width2 then //calculate steps in x, y
begin
@@ -1432,8 +1428,8 @@ SigmaClippedMeanFromHistogram(img,startX,endX,startY,endY,max(65500,trunc(head.backgr*2)), 6,0.1,backgr,noise_level);//mean and noise of this sub section
noise_level:=max(noise_level,0.5); {prevent zero noise}
- detection_level:= 5.5*noise_level;- detection_level_around:=2.2*noise_level;+ detection_level:= 7*noise_level;+ detection_level_around:=4*noise_level; find_stars_routine(startX,endX,startY,endY);
end;
end;
We don't mean the old detector is better in general; the new one presumably rejects hot pixels better. It's only that this ordinary frame (FSQ106 + QHY600M, 1.5"/px) no longer solves.
Best regards,
Igor
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your investigation and feedback are much appreciated. It's rare to receive feedback, and it always helps with further development.
In the latest version, I tried to make star detection more sensitive in order to detect very faint stars. For your M101 image, it manages to solve using the D80 database, but with fewer quads, resulting in a lower-quality solution.
Looking at the detections, it seems that more H-alpha clouds were picked up as stars. So, by increasing the sensitivity, I also introduced more false star detections. See attached screen shot.
I have tested it on several thousand images from nova.astrometry.net, and the new version solves more images than the previous one. However, the side effect seems to be some regression with images like M101.
For now, I agree that there is no need to change anything. However, feedback like yours is important to ensure that it works satisfactorily with all kinds of astronomical images.
Hello Han,
Thank you for ASTAP. We use astap_cli in an open-source observatory-control project, and our nightly test caught a regression in CLI-2026.10.30, which we then bisected with builds from your repository. We see it on Linux x64, Linux arm64, macOS M1 and Windows x64.
Test frame (2 MB, 1024×1024 crop of an FSQ106 + QHY600M frame of M101, pointing keywords removed): m101_known.fits (github.com). Database: D05 (d05_star_database.zip, unchanged since 2026-05).
Command:
CLI-2026.09.01:
CLI-2026.10.30:
What we found:
-threads 1gives byte-identical output, so the parallel search itself does not seem to be the cause.-progress -log, the first pass at the start position finds the field with 5 references, and the second pass finds only 1 and drops it (2026.09.01 finds 8, then 4). After that the spiral continues and finds nothing:-r 180, FOV 0.42 from the header) behaves the same way. The first pass finds the field about 125° from the 0,0 start, which is where M101 is. The second pass then spirals from there out to 180° without a match. Single-threaded that takes 117 s, where 2026.09.01 solved it blind in about 48 s.-fov 0(auto) does solve, at the 0.56° trial with 157 stars (correct centre, Δ 0.1"), then warns "scale was inaccurate! Set FOV=0.42d". So the failure seems to show up when the star budget is tight, at the correct FOV.-t 0.010,-speed slowand-s 1000make no difference.We then built astap_cli from your Mercurial repository to bisect it, with Free Pascal 3.2.3 and
fpc -MObjFPC -Scghi -O1 -XX -Si astap_command_line.lpr. Our builds of 97a3110d0305 and 2e83d86b41fe reproduce the output of your 2026.09.01 and 2026.10.30 binaries exactly.Reverting only the star detection in find_stars on 2e83d86b41fe makes it solve, with output identical to 2026.09.01: 89 stars, 68 quads, Found 8 then 4 references, solved in 0.1 s, and the same CRVAL1 and CRVAL2 to every digit. The revert puts back the 4-pixel cross with at least 2 neighbours, 4σ instead of 6σ on the first try, and 7σ, 4σ and SNR 10 instead of 5.5σ, 2.2σ and SNR 7 in the raster pass. Either half alone does not solve it, and disabling clip_and_refit and the skew check changes nothing.
The revert, against 2e83d86b41fe:
We don't mean the old detector is better in general; the new one presumably rejects hot pixels better. It's only that this ordinary frame (FSQ106 + QHY600M, 1.5"/px) no longer solves.
Best regards,
Igor
Hi Igor,
Your investigation and feedback are much appreciated. It's rare to receive feedback, and it always helps with further development.
In the latest version, I tried to make star detection more sensitive in order to detect very faint stars. For your M101 image, it manages to solve using the D80 database, but with fewer quads, resulting in a lower-quality solution.
Looking at the detections, it seems that more H-alpha clouds were picked up as stars. So, by increasing the sensitivity, I also introduced more false star detections. See attached screen shot.
I have tested it on several thousand images from nova.astrometry.net, and the new version solves more images than the previous one. However, the side effect seems to be some regression with images like M101.
For now, I agree that there is no need to change anything. However, feedback like yours is important to ensure that it works satisfactorily with all kinds of astronomical images.
cs, Han