afeinstein20 / eleanor

A tool for light curve extraction from the TESS FFIs.
MIT License
92 stars 39 forks source link

Correction in plot_gaia_overlay #195

Open VishalJoshiPRL opened 4 years ago

VishalJoshiPRL commented 4 years ago

While generating the LC of a source in a moderately crowded field, I found that the circles representing the Gaia sources are slightly off compared to the TESS sources in plot_gaia_overlay. The shifting of the Gaia source mark is diagonal, which means that the shift is in both axes. After a detailed inspection, it became clear that the shift is present irrespective of the choice of the star or the sector.

I think the shift appears because the pixel coordinates are assigned to the lower-left corner of the pixel (assuming the square-shaped pixel) in the plot generated by tpf.plot(). Ideally, it should be assigned to the center of the pixel. To correct this, I have made the following changes in "def _add_gaia_figure_elements()," and it works now.

1) The origin is changed to 0 in line 336 of visualize.py . The corrected line reads now as follows: coords = tpf.wcs.all_world2pix(radecs, 0)

2) 0.5 is added both X and Y coordinates in lines 346 & 347. The corrected line reads now as follows: plt.scatter(coords[:, 0]+tpf.column+0.5, coords[:, 1]+tpf.row+0.5, c='firebrick', alpha=0.5, edgecolors='r', s=sizes) plt.scatter(coords[:, 0]+tpf.column+0.5, coords[:, 1]+tpf.row+0.5, c='None', edgecolors='r', s=sizes)

I could avoid correction (1) by subtracting 0.5 from coordinates (instead of adding it) in correction (2), but I think keeping origin to 0 is more apparent to be Python-compatible.

Following two images show the plot before and after correction:

Before Correction after correction
benmontet commented 4 years ago

Thanks @VishalJoshiPRL! I haven't looked closely at the code yet; do you believe the issue to be restricted to identifying the location of Gaia targets on the detector or that the TESS targets as a whole on the detector are shifted by a pixel relative to where the WCS thinks they are? I think the issue is likely the former, which your fix would solve, but I would like us to double-check this isn't hiding a more nefarious issue, which would lead to targets being a pixel off, so apertures would be a pixel off, which would lead to worse photometry.