Unexpected pixel values in *.dat vs sextract_single_image

[mrosseel]

version: vast-1.0rc84 Note: the reference frame in 'vast_summary.log' is processed via astrometry.net and saved as new-image.fits.

If I execute the following command: ./sextract_single_image ../../new-image.fits 886 1199

The red cross is over a star. When I click this star I get the following output:

When I look at this same star in either 'vast_list_of_all_stars.log' or in 'out01177.dat', the following coordinates are displayed:

So the question is, is this a bug or is there another way to get the pixel position of a star on the reference frame?

[kirxkirx]

@mrosseel thanks for the very detailed report!

The pixel coordinates reported by sextract_single_image should match the ones in the out*.dat file for the same image for a given star. My guess is that for some reason, it is either not the same image or not the same star. The second screenshot suggest that the star is marked by SExtractor on the reference image with the flag "3" = "heavily blended". By default, VaST will not write measurements with SExtractor flag >1 to the lightcurve file (assuming that photometry of a blended star is unreliable, which is often the case). Maybe for that reason VaST dropped the measurement associated with the reference (and likely a few other) images, but on images starting with 'WWCrA#30V_000184527_FLAT.fit' (the first record in the lightcurve file) seeing got better and SExtractor did not mark this star as blended, so VaST propagated the measurements to the lightcurve file. So my guess is that 'WWCrA#30V_000184527_FLAT.fit' is not the reference image listed in 'vast_summary.log' and solved with astrometry.net

You may tell VaST to accept blended stars by re-running the analysis with '-x3' option: ./vast -x3 ../image/files*.fit but the side effect of this would be a number of false candidate variables arising from corrupted photometry. Another option is to rise the detection threshold in 'default.sex' increasing the value of 'DETECT_THRESH' (and 'ANALYSIS_THRESH') to the point where the target star is not marked as blended any more. According to the first screenshot, the star is fairly isolated and touches its neighbour maybe only with the wings of its PSF. Raising the threshold will make fewer pixels get assigned by SExtractor to the star effectively cutting the PSF at a higher level, eventually at a level where there is no overlap with the image of the neighbouring star. The side effect of this would be loosing the faintest stars, of course.

[mrosseel]

@kirxkirx thanks for the fast reply! The information on the blended star and how to avoid it is interesting. I made some further tests where I used the exact same fits to make sure there's not an error there.

The command: ./sextract_single_image ../../inputfiles/WWCrA2015/fits/WWCrA\#30V_000184527_FLAT.fit 918.8 1180.0

Clicking on the star gives:

Looking the out01208.dat file:

So using the exact same fits file, pgfv is giving other pixel values than the .dat file. Let me know if there is anything else I can check, or if there's a wrong assumption from my part somewhere.

[kirxkirx]

Maybe this is a different star? According to the last two screenshots, './sextract_single_image' reports star 1208 (lightcurve file out01208.dat), but the grep'ed lightcurve is for the star 'out01218.dat '. Also they have very different instrumental magnitudes (-12 and -8, respectively), while they should be the same for the reference image.

The star numbers should remain the same as long as 'default.sex' is not changed and it's the same version of SExtractor running on the same computer. (At least, this should be true for the stars detected on the reference image, i.e. the ones with numbers below the 10000 gap in numbering.)

Also I checked that with the test data set, the pixel coordinates of a star in its lightcurve file and reported by './sextract_single_image' are the same within the rounding error.

[mrosseel]

yes it was a different star, should have seen that.

In the end, I could fix my issues by using '-x 3' to include the blended stars (their lightcurves look ok) and by using the correct file to get my X and Y positions. I was using the X and Y from the data.m_sigma file, but these sometimes deviate from the values in the vast_list_of_all_stars.log. Is this expected behaviour?

Thx for the help!

[kirxkirx]

Glad the problem is solved!

Yes, slight differences in pixel positions are expected between 'data.m_sigma', its more expanded version 'vast_lightcurve_statistics.log' and the lightcurve file on one hand, and 'vast_list_of_all_stars.log' on the other hand. This is for sources detected on the reference image, for other sources (these differences may be arbitrary large as the positions correspond to different frames: the first frame where the source was detected or the reference frame). The file 'vast_list_of_all_stars.log' lists for each detected source its pixel position transformed to the pixel coordinate frame of the reference image and averaged over multiple images, while all the other files mentioned above list the pixel position measured on the first image where the source was detected (for the majority of sources this will be the reference image).