NH at Jupiter, Planning the Jupiter encounter |
NH at Jupiter, Planning the Jupiter encounter |
Jan 22 2006, 10:57 PM
Post
#1
|
|
Member Group: Members Posts: 706 Joined: 3-December 04 From: Boulder, Colorado, USA Member No.: 117 |
I think the Jupiter encounter deserves its own thread.
I've just been taking a first look at the Jupiter encounter geometry. You can do the same using Mark Showalter's excellent on-line ephemeris tools at the PDS rings node, which by good fortune happens to include a New Horizons ephemeris (calculated over a year ago) for our actual launch date, January 19th. We'll have an updated ephemeris soon, but this one's already good enough for planning. As Roby72 noted in the Star 48 thread, the satellites are (annoyingly) all on the opposite side of Jupiter at closest approach. We'll still get good views of all sides of Io because Io rotates in only 1.8 days and we'll be pretty close to Jupiter for that long. We'll get fairly good coverage on Europa too, for the same reason. But we won't get very close to Ganymede or Callisto. Luckily Io is our highest priority satellite target and Europa is next, so we'll do OK. |
|
|
Feb 21 2006, 05:16 AM
Post
#2
|
|
Director of Galilean Photography Group: Members Posts: 896 Joined: 15-July 04 From: Austin, TX Member No.: 93 |
Ah yes, I forgot that CCDs transfer the pixels down and then over. In that case you would get a vertical smear of the image. I assume what you're doing is something like this:
1. Simplified image is like this: CODE 0: 0 1: 0 2: 8000 3: 8000 4: 8000 5: 0 6: 0 2. Pixels are read out from the bottom of the display, with each row dropping down one during the readout. Each pixel read out step would be something like this, ideally: CODE CCD Pixel Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 0 -na- -na- -na- -na- -na- -na- -na- 1 0 -na- -na- -na- -na- -na- -na- 2 0 0 -na- -na- -na- -na- -na- 3 8000 0 0 -na- -na- -na- -na- 4 8000 8000 0 0 -na- -na- -na- 5 8000 8000 8000 0 0 -na- -na- 6 0 8000 8000 8000 0 0 -na- Output row Read 0 Read 0 Read 8000 Read 8000 Read 8000 Read 0 Read 0 3. Since the readout time is comparable to the exposure time, and there is not a shutter, each time a value is in an "exposed" pixel, like 2-4 above, it would get a certain amount of light, depending on how long the value is kept in that pixel. For example, let's say 10% of the exposed value, so 800 in this case since all light pixels are 8000: CODE CCD Pixel Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 0 -na- -na- -na- -na- -na- -na- -na- 1 0 -na- -na- -na- -na- -na- -na- 2 800 800 -na- -na- -na- -na- -na- 3 8800 1600 1600 -na- -na- -na- -na- 4 8800 9600 2400 2400 -na- -na- -na- 5 8000 8800 9600 2400 2400 -na- -na- 6 0 8000 8800 9600 2400 2400 -na- Output row Read 0 Read 0 Read 8000 Read 8800 Read 9600 Read 2400 Read 2400 4. Since you said above that you would need a few complete rows of dark in the image, I guess you are taking the value placed in those last image rows (in this case the 2400 read out in step 6&7) and using that to adjust the previous pixels? How do you subtract out the value, since it’s not going to be linear across real-world light pixels? 5. It should be possible to also do it based on the opposite direction, since you know how long you timed the exposure and what the readout time per line is, and CCDs are pretty much linear. IE, if you have a readout time of 100ms, and 1024 rows, then you would get an additional exposure of 100/1024 or 97us per light pixel on the way off the CCD. So if you took an image 10ms long, you know the first light pixel read out from each column has no extra light, with each following pixel having .097/10=.0097 or about ~1% additional light from each corrected light pixel ahead of it. With this method, you could take full-frame light images, even if the top of the frame is overexposed the lower portions should be recoverable. PS John, I now understand what your problem was wrt that table not keeping the correct spacing. Even if you mark a section as CODE This is a fixed width font. blah 0123456789012345 the editor doesn't switch to a fixed width font. What I did is edit my original table in Outlook with the font set to Courier New, and then copied&pasted it back here with the code tags. PPS Interestingly enough, I did some googling on this, and found out that the IRIS freeware camera software will automatically take care of this issue for you! http://www.astrosurf.com/audine/English/result/obtu.htm http://www.astrosurf.com/audine/English/first.htm#smearing http://www.astrosurf.com/buil/iris/tutoria....htm#deconvflat Well whaddaya know! -------------------- Space Enthusiast Richard Hendricks
-- "The engineers, as usual, made a tremendous fuss. Again as usual, they did the job in half the time they had dismissed as being absolutely impossible." --Rescue Party, Arthur C Clarke Mother Nature is the final inspector of all quality. |
|
|
Feb 21 2006, 03:24 PM
Post
#3
|
|
Member Group: Members Posts: 706 Joined: 3-December 04 From: Boulder, Colorado, USA Member No.: 117 |
^^^Your analysis is almost correct- the additional wrinkle (which I didn't realize myself till recently) is that there is an additional period of smeared exposure *before* the static image is exposed, which looks exactly the same as the readout smear but is in the opposite direction. The result is that all rows in the image, whether "above" or "below" the main target, have exactly the same amount of readout smear in them. This makes it easy to subtract the smear if you have any dark sky rows- you can measure the smear in the dark sky rows and subtract it from all the other rows. We don't yet know how well this will work in the real world (though we are optimistic), and we'll always have to content with the photon noise from the subtracted smear, which can be significant.
|
|
|
Lo-Fi Version | Time is now: 25th September 2024 - 09:04 PM |
RULES AND GUIDELINES Please read the Forum Rules and Guidelines before posting. IMAGE COPYRIGHT |
OPINIONS AND MODERATION Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators. |
SUPPORT THE FORUM Unmannedspaceflight.com is funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member. |