Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out overlapping frames - what they are and how to combine them #7

Open
kstoreyf opened this issue Jul 14, 2016 · 6 comments
Open

Comments

@kstoreyf
Copy link
Contributor

kstoreyf commented Jul 14, 2016

see https://docs.google.com/presentation/d/1LOBqTZBd1ACW3gVC4aTnYxSntBUuSiuK4QCtOLID-is/edit#slide=id.p and @joshwalawender's comment on the slide

when combining light curves from different units of the same target:

  • if the midpoint of a frame (start time + half of exptime) falls within the midpoint extrema of another image sequence, they overlap?
  • if multiple frames overlap, we average their fluxes as a starting approximation? and propagate the uncertainties?
  • then the new timestamp for this combined flux is the midpoint between the midpoints of the overlapping frames, and this datapoint is added to master light curve?
    • with this method, best to recalculate master light curve each time new overlapping frames are added
@joshwalawender
Copy link
Contributor

This gets to a core question. When we build the master light curve, do we want to average any points at all? If the master light curve is just a bunch of time series data points (one for each image in a PSC for each camera) then we can operate on that.

For example, we might try fitting a model (which could grow to include many instrumental terms we can't predict right now) to the light curve. Alternatively, we could perform some sort of bayesian statistical test for the existence of a transition (transit entry or exit) at various points in time along the curve. Since this analysis method is to be explored, I think record data and try some of these ideas out without averaging any data points.

@wtgee
Copy link
Member

wtgee commented Jul 14, 2016

I think we need @oguyon to comment.

See also section 3.4 on his (very outdated) page:
http://www.naoj.org/staff/guyon/09allskysurvey.web/56photometry.web/content.html

@kstoreyf
Copy link
Contributor Author

if for now we consider the curve as time series data points, should the times be the start time of the exposure or the midpoint?

or if @oguyon or anyone has other thoughts on combining light curves, would be appreciated

@wtgee
Copy link
Member

wtgee commented Jul 20, 2016

Typically you go from the mid-point of a transit but I do think we will
want to wait for @oguyon for a few things.

On Thu, Jul 21, 2016 at 5:53 AM, kstoreyf [email protected] wrote:

if for now we consider the curve as time series data points, should the
times be the start time of the exposure or the midpoint?

or if @oguyon https://github.com/oguyon or anyone has other thoughts on
combining light curves, would be appreciated


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#7 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEUUOmBFaINu-uOlZy-Ptt8p0aniWEYks5qXnzJgaJpZM4JL_ay
.

~Wilfred Tyler Gee

@oguyon
Copy link

oguyon commented Jul 22, 2016

  • sorry for the slow response ... long observing run ongoing on Subaru -

As Josh points out, we probably want to keep the raw measurement points
all the way into the final step of the detection algorithm
averaging is not always the best thing to do - we'll want to remove
statistical outliers, and quite possibly store/explore
cross-correlations between measurements

I envision that the data product from a single observation on a star
would be a set of single exposure flux measurements in 3 colors

On 07/13/2016 03:10 PM, Josh Walawender wrote:

This gets to a core question. When we build the master light curve, do
we want to average any points at all? If the master light curve is
just a bunch of time series data points (one for each image in a PSC
for each camera) then we can operate on that.

For example, we might try fitting a model (which could grow to include
many instrumental terms we can't predict right now) to the light
curve. Alternatively, we could perform some sort of bayesian
statistical test for the existence of a transition (transit entry or
exit) at various points in time along the curve. Since this analysis
method is to be explored, I think record data and try some of these
ideas out without averaging any data points.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7 (comment), or
mute the thread
https://github.com/notifications/unsubscribe/AFVuDahd74zJaLhwTQR5ClqCYAzuNkpyks5qVYyYgaJpZM4JL_ay.

@oguyon
Copy link

oguyon commented Jul 22, 2016

exposure midpoint time is better as it makes it easier to mix data
points taken with different exposure times

as for transit detection, the ideal case is to observe a full transit
with a single PANOPTES observation. Most of the time, though, a single
observation will only catch the beginning or end of transit, and the
goal is to detect, from a single observation, a sharp drop or increase
in flux.
Merging data from multiple units then becomes equivalent to lining up
these "edge detections" into a periodic ON/OFF transit pattern

On 07/20/2016 10:02 AM, Wilfred Tyler Gee wrote:

Typically you go from the mid-point of a transit but I do think we will
want to wait for @oguyon for a few things.

On Thu, Jul 21, 2016 at 5:53 AM, kstoreyf [email protected]
wrote:

if for now we consider the curve as time series data points, should the
times be the start time of the exposure or the midpoint?

or if @oguyon https://github.com/oguyon or anyone has other
thoughts on
combining light curves, would be appreciated


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#7 (comment),
or mute
the thread

https://github.com/notifications/unsubscribe-auth/AAEUUOmBFaINu-uOlZy-Ptt8p0aniWEYks5qXnzJgaJpZM4JL_ay
.

~Wilfred Tyler Gee


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#7 (comment), or
mute the thread
https://github.com/notifications/unsubscribe-auth/AFVuDSV74FWQtFljfXHF8KcuFBDFl3Clks5qXn7SgaJpZM4JL_ay.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants