NH at Jupiter, Planning the Jupiter encounter Options

[john_s]

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.

[hendric]

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!