Menu ▾ ▴

ASTAP CLI 2026.10.30 no longer solves a frame 2026.09.01 solved: bisected to the new star detection in find_stars (patch included)

3 days ago
2 days ago
  • Igor von Nyssen

    Igor von Nyssen - 3 days ago

    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:

    astap_cli -f m101_known.fits -d <d05 dir> -wcs -ra 14.0540 -spd 144.3469 -fov 0.42 -r 3.0
    

    CLI-2026.09.01:

    89 stars, 68 quads selected in the image. 140 database stars, 107 database quads required for the 0.53d square search window. Step size 0.42d. Oversize 1.25
    4 of 4 quads selected matching within 0.007 tolerance.
    Solution found: 14: 03  14.4 +54d 20  49
    Solved in 0.1 sec. Δ was 0.3".
    

    CLI-2026.10.30:

    88 stars, 68 quads selected in the image. 140 database stars, 108 database quads required for the 0.53d square search window. Step size 0.42d. Oversize 1.26
    1THREAD,1d,1d,2d,2d,3d,No solution found!  :(
    

    What we found:

    • -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:
    2026.09.19: 34, 82, then 175 stars found (raster detection level 77); 89 kept after selecting the brightest
    2026.10.30: 33, 83, then 229 stars found (raster detection level 61); 88 kept after selecting the brightest
    

    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

     
  • han.k

    han.k - 2 days ago

    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

     

Log in to post a comment.