Checkerboard images

[JohnPritchard]

Dear Emmanuel,

I am developing a sextractor+scamp+swarp "pipeline" to deal with FORS (and eventually other ESO instrument) data. I begin by processing a set of 18 of observations of a standard star field. The majority process well and produce a perfect acceptable looking astrometrically calibrated image.

But five of them result in a "bad" image from swarp, when displayed in ds9, I see a "checkerboard" pattern. The sextractor and scamp phases seem (to my non-expert eye) to run "correctly" and produce "sensible" results. See:

http://www.eso.org/~jpritcha/swarp_checkboard_ims.tgz

for an example (run the commands in the README to reproduce my processing).

Is this an issue in SWarp, or am am I doing something wrong?

There are also subdirectories to process the two images individually, you'll see that one results in an OK file (tk4xgdol), while the other (8xh87oir) has the same checkerboard pattern. I also tried processing the two sextractor cats together in a single scamp execution (8xh87oir+t4xgdol) but I get the same result.

Best regards John Pritchard

P.S. I'm running this on macOS-10.15 with sextractor+scamp+swarp built in a MacPorts environment (Portfiles available on demand). I checked this quickly on a fedora-31 virtual machine using the RPMs availbale via yum, and got he same result.

[JohnPritchard]

Oh, I should add, although I had initially been using the AstroMatic.net source versions, this morning I updated to the current GitHub latest releases for all three packages but it made no difference.

For convenience, here's a screenshot of the checkerboard pattern as seen in ds9:

[JohnPritchard]

And now paying more attention, I note that sextractor actually produces several warnings and that the check image has the checkerboard problem:

$ sex -c 8xh87oir_sex.cfg 8xh87oir.fits
----- SExtractor 2.25.0 started on 2021-02-15 at 14:16:11 with 1 thread

----- Measuring from: 8xh87oir.fits
      "STD" / no ext. header / 2048x1024 / 32 bits (floats)
(M+D) Background: 125.576    RMS: 13.2962    / Threshold: 19.9443    
> Line:  550  Objects:     4680 detected /     1481 sextracted
**> WARNING: Pixel stack overflow at position 550,566**

      Objects: detected 5776     / sextracted 5451            

> All done (in 1.7 s: 591.9 lines/s , 3150.9 detections/s)
$ sex -c tk4xgdol_sex.cfg tk4xgdol.fits
----- SExtractor 2.25.0 started on 2021-02-15 at 14:17:01 with 1 thread

----- Measuring from: tk4xgdol.fits
      "STD" / no ext. header / 2048x1024 / 32 bits (floats)
(M+D) Background: 122.857    RMS: 11.5885    / Threshold: 17.3828    
> Line: 1024  Objects:     3165 detected /        0 sextracted
**> WARNING: Deblending overflow for detection at 1,1**

**> WARNING: Deblending overflow for detection at 1,1**

      Objects: detected 3436     / sextracted 2902            

> All done (in 1.5 s: 701.3 lines/s , 1987.4 detections/s)

What do these mean, and are they (or at least the pixel buffer) causing the checkboard problem?

[JohnPritchard]

Hmmm, I reinstalled sextractor-2.25.0 (recompiled from source), and now sextractor is well behaved... no Warning messages, no checkerboard pattern in the check image.

[JohnPritchard]

Correction: I still get the warnings on the above sextractor commands, but I confirm no checkerboard pattern in the check image.

[JohnPritchard]

I am fully updating my MacPorts installation, and then will re-install sextractor+scamp+swarp from source to check if this (somehow magically) solves the checkerboard issue. Stay tuned...

[JohnPritchard]

So with MacPorts fully up to date, and sextractor+scamp+swarp built fresh from source, I still get the checkerboard issue in SWarp images.

[ebertin]

Hi John, sorry for not replying earlier. SWarp's background modelling engine appears to be confused by the presence of a bunch of weird pixel values (+/- 10²¹) in 8xh87oir.fits (division by flatfield values close to 0?). This creates the sort of wave you are seeing because of the background interpolation spline. SWarp's median filter seems ineffective because the bad pixels are right in the corner. The effect subsides if you choose a background mesh large enough, but I would suggest clipping these values nevertheless.

[JohnPritchard]

Hi Emmanuel, Many thanks for the constructive feedback and for taking the time to make a careful analysis. I will adjust things accordingly and let you know. John

[JohnPritchard]

Hi Emmanuel, Actually since these files are pipeline products, the background has (mostly) been corrected, so (at least for my present purposes) I can simply turn off the bkg correction in SWarp and then the coated images look beautiful! Thanks again! I think you can close this ticket as resolved. best regards John