superbit-collaboration / superbit-metacal

Contains a collection of routines used to perform gmix/metacalibration on simulated SuperBIT images
4 stars 0 forks source link

Coadd images in grid_test have bad stellar images #107

Open emhuff opened 1 year ago

emhuff commented 1 year ago

Bright objects in the coadd image appear stretched, and their vertical surface brightness profiles are negative.

This isn't there in the single-epoch images. The source positions in single-epoch are properly registered, so this likely isn't being introduced by coaddition in the presence of a bad WCS.

image

sweverett commented 1 year ago

One small additional bit of info: The failure modes don't appear to be source class specific. Here is a cutout with a galaxy on the bottom left and a star on the top right, each with the failure mode. Instead it seems to happen for the brightest objects; each of these have pixel counts in the low thousands, compared to low dozens for typical objects in the image

image
sweverett commented 1 year ago

I looked at these sources in all of the produced images from imsim. They are perfect circles in the single-epoch images and expand about the y-axis only in the single-band coadds (both bands). The negative regions appear only when creating the detection coadd.

While I need to do some more digging, it also appears that there may be an inconsistency between the WCS's of the single-epoch and coadd images. While a shift can happen when the coadd is larger than the single-epoch images, that is not the case here

mcclearyj commented 1 year ago

This is a known issue in SWarp. The interpolation of input image pixels onto the coadd introduces artifacts near bright stars, saturation trails, and other discontinuities. The strength of the artifact depends on the choice of interpolation kernel (nearest-neighbor, bilinear, Lanczos2/3/4). SWarp documentation claims that Lanczos3 is the best compromise between preserving signal and preserving the noise spectrum for correctly sampled data. Bilinear interpolation would lead to fewer artifacts at the expense of correlating neighboring pixel values. More details are in the Swarp documentation on this page in Section 6.6 and see Figure 6 in particular.

As these artifacts are only expected near bright stars, do we anticipate a problem with source selection on the detection image? swarp (1).pdf

sweverett commented 1 year ago

Thanks @mcclearyj! I haven't followed up on this yet, but I found that it was happening for both bright stars and galaxies, though they were multiple factors away from saturation. The bright galaxies were a bit unusual in the sense that they were perfect circles - the light would be more spread out in realistic cases.

andrevitorelli commented 1 year ago

I'm looking into the outputs from source extractor at grid_test_cat_b.fits versus the grid_test_coadd_b.fits image. Here is one bright star that exhibits elongation along the Y axis, as we have seen with bright objects:

Here we see the elongation along the Y direction

Here we see the projection in the X direction, along the horizontal green line on the image above.

Here we see the projection in the Y direction, along the vertical green line on the image above.

And these are the values from the detection catalog for this object:

{'ALPHAWIN_J2000': 199.60440437313355,
 'DELTAWIN_J2000': 33.141747129718375,
 'X_IMAGE': 2552.4976,
 'Y_IMAGE': 4260.0444,
 'NUMBER': 510,
 'MAG_ISO': 16.906605,
 'MAGERR_ISO': 0.002274858,
 'MAG_ISOCOR': 16.906199,
 'MAGERR_ISOCOR': 0.0022745917,
 'MAG_APER': 16.896029,
 'MAGERR_APER': 0.002254051,
 'MAG_AUTO': 17.75238,
 'MAGERR_AUTO': 0.0033602424,
 'MAG_BEST': 17.75238,
 'MAGERR_BEST': 0.0033602424,
 'FLUX_AUTO': 79258.836,
 'FLUXERR_AUTO': 245.23839,
 'FLUX_BEST': 79258.836,
 'FLUXERR_BEST': 245.23839,
 'FLUX_ISO': 172726.02,
 'FLUXERR_ISO': 361.8114,
 'KRON_RADIUS': 2.5,
 'BACKGROUND': -0.053205445,
 'THRESHOLD': 5.2002454,
 'FLUX_MAX': 31703.943,
 'ISOAREA_IMAGE': 32,
 'X2_IMAGE': 1.0199307143437029,
 'Y2_IMAGE': 1.0212298750233941,
 'XY_IMAGE': 0.0014956649136728117,
 'YMIN_IMAGE': 4255,
 'YMAX_IMAGE': 4265,
 'XMIN_IMAGE': 2549,
 'XMAX_IMAGE': 2556,
 'A_IMAGE': 1.0110445,
 'B_IMAGE': 1.0094304,
 'THETA_IMAGE': 56.737865,
 'MU_THRESHOLD': 24.34254,
 'MU_MAX': 14.493308,
 'ISOAREA_WORLD': 4.9088676e-08,
 'X_WORLD': 199.6044043579235,
 'Y_WORLD': 33.141647950075225,
 'A_WORLD': 3.9599166e-05,
 'B_WORLD': 3.9535924e-05,
 'THETA_WORLD': -56.779278,
 'FLAGS': 0,
 'FWHM_IMAGE': 6.0238433,
 'FWHM_WORLD': 0.00023593334,
 'ELONGATION': 1.0015991,
 'CLASS_STAR': 0.99797505,
 'FLUX_RADIUS': 2.0122612,
 'FLUX_APER': 174416.8,
 'ELLIPTICITY': 0.0015964508,
 'SNR_WIN': 481.38074}

Of interest, notice that the ELLIPTICITY is really small, despite the elongated appearance.

Also, one thing that I have been constantly observing, thought I cannot guarantee is 100% of the time, is that the center of these objects seem to be inside a pixel in the X axis, but on the pixel border on the Y axis (it is the other way around, I get confused with these: Y axis the peak seems to be at the pixel location, X axis on the border). As I have already had problems with these in the past (there in the context of shape measurement with metacal), this might be something to be investigated.

I will post some of the plots I made for fluxes from input "truth" catalog to the extracted values next.

andrevitorelli commented 1 year ago

Using bilinear interpolation in swarp, as suggested by @mcclearyj does solve the issue. I'm unsure about noise properties of the image, but I don't think know if this is a major issue.

mcclearyj commented 1 year ago

Great, glad to hear it. Did changing kernels solve the sub-pixel (mis)alignment issue noted above, too? That would be more surprising.

On Tue, Jan 10, 2023, 11:51 PM Andre Zamorano Vitorelli < @.***> wrote:

Using bilinear interpolation in swarp, as suggested by @mcclearyj https://github.com/mcclearyj does solve the issue. I'm unsure about noise properties of the image, but I don't think this is a major issue.

— Reply to this email directly, view it on GitHub https://github.com/superbit-collaboration/superbit-metacal/issues/107#issuecomment-1378237371, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLXI3TEG5EXWRYCR6QZFEDWRY33NANCNFSM6AAAAAATRK3SCU . You are receiving this because you were mentioned.Message ID: @.***>

andrevitorelli commented 1 year ago

So, I'm still unsure if this is an alignment issue with swarp, or a property of the grid.

I have, however, looked into detection with different swarp configurations, and using bilinear interpolation causes problems. From a truth catalogue of 558 objects in the grid test, on coadds with LANCZOS3, source extractor finds 541 objects (not totally pure or complete). With BILINEAR, we get 2027 (!) - so, very impure (and still not complete). Worst of all, this would be terrible for data compression needs.

mcclearyj commented 1 year ago

Hi Andre,

What exactly are you trying to do? If your main concern is an image no ugly defects for cosmetic reasons, then a lower interpolation makes sense. If you wanted an image with better noise properties, then a higher order interpolation makes sense. Those artifacts you originally noted may be ugly but will not affect source detection for the majority of real galaxies, which will be quite dim in a 300 second exposure.

Also, detecting 541/558 objects (completeness = 97%) seems pretty good to me, but I don't know whether your tests were supposed to generate 100% completeness. If that is the case, maybe try upping the surface brightness of your galaxies.

Regarding the high number of sources in the bilinear compression, just increase the detection and analysis thresholds in the Source Extractor configuration file. That is a change in two values and should solve your problem. Back in the day, @sweverett and I went through the exercise of testing purity vs. completeness for a range of detection and analysis thresholds. We made a spreadsheet detailing our findings to which I have just sent you an invitation. That approach would help your case.