Another good session last night. It was still pretty cold so I just ran for a couple hours -- from 02:49 to 05:21. I was aware that an Io egress was supposed to happen, but I couldn't remember when it was and because of my setup, it wasn't easy to check. So I didn't pay much attention and just enjoyed "sitting back" and watching the show.
Indeed at about 03:43 (I have no way of confirming this since I didn't actually record it, but this site says so) Io appeared. Here's a before and after image set:
Figure 1: The Jupiter system showing Io egress |
I did a hand-eye measurement of the distance between Io and Jupiter and got 42.12 arcseconds. According to this site, the distance was 39.24 arcseconds. So I'm within one pixel of the predicted distance. Not bad.
Calibration Woes
I'm seeing two problems with the data and I think they're both systematic and I hope measureable and calibratable. The first one I've alluded to in previous posts -- the tendency for the targets to be "bright" when they enter the field of view and slowly "dim" as they move across the FOV. This is a general tendency but not 100% consistent.
I took some data last night that should show this problem if it's something inherent with the hardware. A series of fifteen, 1 minute exposures were taken to produce star streaks across the entire array. The results all look about like this:
Figure 2: 1 minute exposure star trails |
A plot along the bright trail on the right in this image produces this:
Figure 3: Plot along a bright trail |
As you can see, except for some wiggles, there is no general tendency for the target to be brighter when entering the image (the left side of the plot) and progressively fainter as it leaves the image (the right side of the plot).
So what accounts for what I'm seeing in the data? I don't know (yet!).
The other systematic problem I'm seeing is that the data seems to get noisier as the night progresses. The following is a plot of the brightness of Callisto as a function of time. As you can see, the data at the beginning of the night is pretty tight. At the end of the night, however, the data is quite a bit more scattered (although the mean looks consistent).
Figure 4: Callisto photometry 02 April 2014 UTC |
Why? This data has been corrected for atmospheric extinction, so why am I seeing this progressively larger scatter?
I've seen this in other data. My only guess at this moment is that there are other factors with extinction that I'm not taking into account. I don't think it's higher-order terms since the overall plot looks "flat". However, something is making this data scatter more, and the only thing that's changing on my end is that I'm looking through progressively more atmosphere.
Io and Europa Mutual Event
During the 02 April 2014 UTC sesssion, Io and Europa passed very close to one another. Here's a picture of the event:
Figure 5: Io and Europa in a near miss |
My software would see the image on the left as a single target and will therefore show a brightness that's the combination of the two moons. Over time, the two separate enough to allow the software to detect both as separate targets. The photometry for each will settle into its spot. This is indeed what I've got, with some surprises.
Figure 6: Io and Europa photometry during a mutual event |
The green points are Io, and the red points are Europa. Europa was speeding towards the back of Jupiter at the time, and at about 05:51 UTC it got too far into the bright disk of Jupiter to be detected by my software.
So indeed at the beginning of the session, the two moons has a combined brightness. At about 04:07 UTC, they started to separate enough that they began to appear like two targets instead of one. This took place over the course of several minutes (about 04:07 to 04:28 UTC) until as you can see on the right side of the plot, there are two distinct targets with different brightnesses.
However, there are structures within these plots that I can't account for. Looking at the Io data (the green points), there's a very obvious smooth drop in brightness from about 04:30 to 05:00 UTC. After that, the photometry looks pretty steady (with the exception of the aforementioned larger scatter).
This same dip in brightness appears in the Europa data but for a shorter period of time (about 04:30 to 04:43 UTC). Europa is close enough to Jupiter that I'm not sure how seriously to take the points after about 05:00 UTC.
I should probably write a simulation to see perhaps more clearly what the photometry is supposed to be doing. But my guess is that those dips probably shouldn't be there unless there's something else going on.
My only guess at the moment is that maybe I'm seeing the "atmospheres" of these two moons as suggested by Degenhardt in what he calls "atmospheric extinction".
Relative Photometry
Because of the ongoing systematic problems, I'm inclined to take a hard look at doing relative photometry and see if these problems sort of "go away". The problem with relative photometry is that I'm not going to be able to easily separate out which moon is contributing what to the resulting light curves. Once in a while I'll get a bright-enough star in the FOV, but I can't rely on that so the curves will be one target's brightness compared to another's.
Asteroid Data Hunter
This project is a joke. I don't say this because I lost the first phase, but because the entries are nothing like what's needed to detect asteroids. So I've decided to not waste my energy on this and instead work on something more direct -- especially since I now have actual data to work with. Here's part of an email that I've sent to the PI for the CSS:
Part of my reason for writing you is to tell you that this winning Problem Statement is seriously flawed. It's not flawed because the creator is stupid or a poor writer, or that the reviewer is stupid. It's flawed because of ignorance about the problem itself. The winning Problem Statement document very clearly shows this ignorance, and the fact that it won the competition shows this ignorance extends to the reviewer. For example, things that are irrelevant to asteroid detection and astronomical imaging in general are included, and things that are very relevant are left out. The blind are leading the blind.
...
I've come to the conclusion that this competition will fail to produce the results you're looking for. The law of "garbage in, garbage out" applies. You cannot simply *hope* that a reasonable algorithm results from this competition. With what I've seen so far, it would be *incredible luck* that you get anything that works at all -- much less, better than what you already have.
I've further come to the conclusion that my entry will fall onto the ignorant eyes of the reviewers and testers. Because of MY ignorance about the details of how TopCoder works -- and despite my best efforts -- my entry will most likely fail. I'll be producing oranges instead of apples again. My work will be ignored not because it's a terrible solution, but because it doesn't fit within the flawed parameters set forth. I'd prefer that to not happen.
...
I want you to be as successful in detecting as many asteroids (NEOs or otherwise) as you possibly.can. I want the algorithm I've developed to be used for this important and exciting work. So I give you an unsolicited gift: Everything I have in regards to asteroid detection is yours. No strings attached. No acknowledgement or compensation necessary. I will work with you at any level you wish to make this happen.
...
I'm sure you'll see the value in what I'm giving you and I hope you won't blow me off as some idiot guy who *thinks* he has the best solution to a very difficult problem and is just angry about not winning the competition. I don't care about winning or losing. I also don't claim to have the best solution. I claim to have a solution that produces very accurate and reliable results. I'm certain you'll be pleased to see that for yourself.
I have two sets of the their data -- two sets of four images. I also have their detection and rejection files. So my plan is to proceed and get some code written to do what I described in my ADH phase 1 entry paper.
No comments:
Post a Comment