Juno PDS data |
Juno PDS data |
Jan 8 2016, 10:15 PM
Post
#1
|
|
Administrator Group: Admin Posts: 5172 Joined: 4-August 05 From: Pasadena, CA, USA, Earth Member No.: 454 |
There is now PDS-format JunoCam cruise and Earth flyby data available; it's been submitted to the PDS, but MSSS has gone ahead and posted it on their website. I've created an index page to it here. Unlike my usual index pages, there aren't any thumbnails because of the odd nature of JunoCam images, with their long skinny shapes and interleaved framelets. I haven't played much with these data because it's a bit beyond my skill -- I look forward to seeing what any of you can do with it.
-------------------- My website - My Patreon - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
|
|
|
Mar 1 2018, 12:08 PM
Post
#2
|
|
Senior Member Group: Members Posts: 2346 Joined: 7-December 12 Member No.: 6780 |
The effect in your comparison is indeed larger than I remembered. For the small marble movie images, a misalignment of one or two pixels can be rather obvious.
For PJ08, I've performed calibration runs only for the early approach phase, but with several different sets of assumptions. For the same assumptions used in the above PJ09 calibration run, the best-fit data have been around .002 radians rotation around JunoCam's optical axis. But this might have convoluted unmodeled s/c or camera properties specific to the position of Jupiter in the early approach images. During the first few hours after a s/c op, Juno may oscillate a bit, before it's dampened down to the level of statistical noise. |
|
|
Mar 1 2018, 03:46 PM
Post
#3
|
|
Senior Member Group: Members Posts: 2517 Joined: 13-September 05 Member No.: 497 |
During the first few hours after a s/c op, Juno may oscillate a bit... True. If you're using the C kernel, any oscillation should be captured in the kernel. If you're not using the C kernel, then all bets are off. I still find it hard to tell in this whole exchange if people are using the C kernel, and if so, how and when. If there are errors in the angular offsets for Junocam in the I kernel and frames kernel, or if there's spacecraft motion not being captured in the C kernel, I'd like to know about those problems so they can be fixed. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Mar 5 2018, 11:22 PM
Post
#4
|
|
IMG to PNG GOD Group: Moderator Posts: 2251 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
True. If you're using the C kernel, any oscillation should be captured in the kernel. If you're not using the C kernel, then all bets are off. I still find it hard to tell in this whole exchange if people are using the C kernel, and if so, how and when. If there are errors in the angular offsets for Junocam in the I kernel and frames kernel, or if there's spacecraft motion not being captured in the C kernel, I'd like to know about those problems so they can be fixed. There are definitely differences between how we are doing this. My processing differs in some ways from what Gerald or Brian (or someone else) are doing although the fundamentals should be the same. Regarding C kernels, I always use orientation data from the C kernel for every R/G/B set of framelets (typically 25-40 sets per image) and I also do this for the spacecraft position. If possible, as a 'sanity check' I would be interested in knowing the typical pointing errors I should be getting if I use the START_TIME+0.068 seconds in combination with 'frame number' times (INTERFRAME_DELAY+0.001) as the time when extracting the pointing from the C kernel (I sometimes adjust the 0.068 value slightly). I determine the pointing errors using limb fits in images that have been geometrically corrected using the appropriate Brownian distortion parameters. The typical pointing error I get is ~10 pixels but this varies a bit (it's rarely less than ~3 or bigger than 20). The pointing correction varies a bit from the first framelet set to the last (using constant correction would increase the artifacts at the limb that have been discussed in the preceding posts and the color at the limb near the top and/or bottom can get messed up). I think everything I'm doing works correctly, partially because for images where I know the pointing to be accurate I get the expected result, i.e. no pointing error (example: the Cassini image subset where C-smithed C kernels are available). However, I'm not quite as sure as I'd like to be that everything is corrrect. The reason is that debugging this thing isn't completely trivial when I don't know exactly which result I should be getting (in particular I don't know how big the pointing error really is). However, it's probably encouraging that I have *probably* noticed artifacts in images not processed by me that could indicate pointing errors similar that what I've been getting. The pointing correction can be omitted (and I sometimes omit it). However, doing so can result in obvious color artifacts near the limb while artifacts far from the limb are much smaller and often not of significance unless you want very high geometric accuracy. |
|
|
Mar 6 2018, 03:06 AM
Post
#5
|
|
Senior Member Group: Members Posts: 2517 Joined: 13-September 05 Member No.: 497 |
Regarding C kernels, I always use orientation data from the C kernel for every R/G/B set of framelets (typically 25-40 sets per image) and I also do this for the spacecraft position. This is the only method I would have imagined would be adequate without a lot of manual tweaking, and it's the way the MSSS processing works. As far as I can tell from reading Brian's Mathematica code (I don't have Mathematica and the raw ASCII is not the easiest thing to read) he isn't using the C kernel data and he only uses the spacecraft position at the beginning of imaging, but his results are very good so perhaps this doesn't matter in most cases. As for the expected errors, using our parameters the position error of the galilean satellites on orbit 1 had standard deviations of about 1 in X and about 2.8 in Y. I attribute the higher Y error to timing slop, but we could have residual geometric distortion error because the satellites were probably near the optic axis where distortions are lower. For obscure reasons, our own standard processing isn't using our updated parameters yet, though. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Mar 6 2018, 04:03 AM
Post
#6
|
|
Member Group: Members Posts: 411 Joined: 18-September 17 Member No.: 8250 |
.. As far as I can tell from reading Brian's Mathematica code (I don't have Mathematica and the raw ASCII is not the easiest thing to read) Ewww (that stuff isn't pretty). If you download and install the much too large CDF Player you'll be able to view the document properly formatted. (Hover over the right side to show section expansion controls.) QUOTE he isn't using the C kernel data and he only uses the spacecraft position at the beginning of imaging, but his results are very good so perhaps this doesn't matter in most cases. My simple pipeline doesn't do map projection, so it doesn't use position. The only thing it uses from SPICE is Angular Velocity Magnitude for the spin rate. |
|
|
Lo-Fi Version | Time is now: 4th June 2024 - 02:08 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. |