Use positionally-dependent FWHM in simple transient detection

[PYLimapper]

Hello !

I am trying to understand why I get a list of false positive transient detection using STDweb. Here is a complete export of the task output :

Task 166 _ STDWeb.pdf

Could you help me ? When I look a the detected transients into CDS portal / Vizier : I find objects where the catalog magnitude and the measured magnitude differ less than indicated in the column "mag" of the transient found by stdweb.

[arGth56]

source image : https://we.tl/t-Ot9dSuecwx

[karpov-sv]

That's the main deficiency of simple (catalogue-based) transient detection - it is critically dependent on the actual algorithm of source extraction / deblending. In this specific case, SExtractor with default settings splits the central source into two detections as the PSF here is elongated due to optical distortions. First one gets rejected by comparison with catalogues, while second one does not, and thus is reported here.
Due to that, you should always visually inspect these candidates. E.g. if you turn on marking of the center, as on the attached image, you will see that it is indeed slightly shifted w.r.t. the atlas source. It might be actual off-nucleus transient - but as all the stars around are elongated this way, visually you immediately spot that it is not.

[karpov-sv]

The code now computes the matching radius based on mean image FWHM - but in your image the star sizes are significantly larger in these edges w.r.t. the center, and so it does not work well. I am thinking about introducing position-dependent FWHM but see no easy way to implement this...

[arGth56]

If you find a way to adjust the FWHM model depending on the location that would be amazing ! Maybe an option would be to :

1. Process the image in n^2 tiles each one with a specific FWHM value ?
2. If a candidate is detected is less than [adjustable value in arcsec] away from a catalog star entry we filter it out : we could even split between galaxy entries and star entries to apply this only to stars ?

FWHM maps seems to be quite always the same, it may be an optical train alignment issue.

I will see if sensor can be tilted to correct this effect.

To make your system work in the best conditions, what FWHM value / homogeneity would you need ?

I will present the STDweb platform to the RAPAS team mid-april, it would be used by more or less 25 users with their observatories, probably FWHM values will not be amazing nor homogeneous but we we will still try to make best of this source of data.