-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Fix Off-By-One error in column and row coordinates #8
Conversation
I tried using "git reset" to reverse your merges back to July 7th and I get good agreement using the exact same method as above. So your recent changes do appear to be introducing the large error. |
Hi @barentsen, I discovered what changed. Previously, in the tess-cloud generated tpf the fields If I have related question. There is a namespace conflict. I notice that tess-cloud has its own TargetPixelFile class. This supersedes the TargetPixelFile class in LightKurve and yet doesn't inherent it. Why do you do this? My MovingTargetPixelFile class inherents the TessTargetPixelFile class in LightKurve, not tess-cloud. Now I'm not sure which I should inherent. |
Ahhh, yes, that is correct! This change was made to enable cutouts of non-moving objects to be plotted correctly in Lightkurve, because e.g.
This of course depends on how we want to define
The |
I think we need to change something. Having them be in absolute coordinates makes the most universal sense. I agree that |
Over in #7, @jcsmithhere correctly pointed out that tess-cloud currently interprets column and row coordinates in the "0-based indexing" scheme. This is inconsistent with the convention for the TESS mission, which is to use 1-based indexing for pixels. As a result, cutouts produced by tess-cloud are consistently off by one pixel in both the column and the row direction.
This PR fixes the issue and adds a unit test which compares the fluxes returned by tess-cloud with those obtained via TessCut, which acts as an effective test to verify that column/row indexing is consistent with the convention used by TessCut.
Below I post a before/after example. The example demonstrates how I reproduced the issue, and that the PR fixes the example shown.
Behavior before this PR
Behavior with this PR merged