Comments (5)
@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.
from vast.
@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.
from vast.
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.
from vast.
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!
from vast.
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).
from vast.
Related Issues (8)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vast.