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.
|
|
|
Sep 5 2017, 09:29 PM
Post
#2
|
|
IMG to PNG GOD Group: Moderator Posts: 2254 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
The new frame and instrument kernels (plus information/comments they contain) mentioned in the previous post have eliminated most of the systematic errors I have been getting, meaning that the corrections I need to make to the camera pointing are now much smaller. What I'm doing is comparable to what ISIS3's deltack does. However, small errors apparently remain. Because of this there is one issue I hope Mike can clarify (I suspect Gerald also knows something about this).
juno_junocam_v02.ti has lines like this: INS-6150#_DISTORTION_X = 814.21 The width of the images is 1648 pixels. Does the above line mean that the optical axis passes through x=814.21 in the images and not width/2 (=824) as in other spacecraft cameras (e.g. Cassini, Voyager, Galileo and Dawn) I'm familiar with? |
|
|
Sep 5 2017, 10:58 PM
Post
#3
|
|
Senior Member Group: Members Posts: 2542 Joined: 13-September 05 Member No.: 497 |
Does the above line mean that the optical axis passes through x=814.21 in the images and not width/2 (=824) as in other spacecraft cameras (e.g. Cassini, Voyager, Galileo and Dawn) I'm familiar with? Yes. At least that's what we are suggesting you use in the camera model. No camera really has the optic axis going directly through width/2 -- if it says it does, that most likely only means that other parts of the camera model have been adjusted to compensate for that assumption (camera model parameters don't have to be physically accurate as long as the residual errors are low.) For this most recent kernel update, we (a summer intern and I) measured thousands of cruise star image locations and then used Nelder-Mead nonlinear optimization to minimize camera model error while varying seven model parameters: image optical center (cx, cy), the first two terms in the radial distortion function (k1, k2), camera focal length (fl), and camera boresight angular misalignment in X and Y (xr, yr). The residual error is still about 1 pixel cross-spin and ~2.5 pixels down-spin (1 sigma); the latter higher because of remaining timing slop. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Sep 25 2017, 05:24 AM
Post
#4
|
|
Member Group: Members Posts: 425 Joined: 18-September 17 Member No.: 8250 |
For this most recent kernel update, we (a summer intern and I) measured thousands of cruise star image locations and then used Nelder-Mead nonlinear optimization to minimize camera model error while varying seven model parameters: image optical center (cx, cy), the first two terms in the radial distortion function (k1, k2), camera focal length (fl), and camera boresight angular misalignment in X and Y (xr, yr). The residual error is still about 1 pixel cross-spin and ~2.5 pixels down-spin (1 sigma); the latter higher because of remaining timing slop. Hi Mike, I’ve also been looking at PDS cruise phase full-rotation color images for camera geometry calibration. I noticed what appear to be changes in compression artifacts between datatakes without an indication of a change in the .LBL file. For example, between JNCE_2016026_00C00063_V01 and JNCE_2016026_00C00064_V01. Could you comment on that? I also wonder if there are opportunities for non-standard imaging around apojove (or any time Jupiter is fairly small in the FOV). If so, some imagery I think could be useful are: 1. Command JunoCam to disable TDI and capture a full rotation of color frames with EXPOSURE_DURATION around 464ms to 816ms. The goal being to capture bright stars or moons as slightly curved trails passing over filter boundaries, which could then be used to help characterize chromatic aberration and geometry. Ideally, collect several of these at different altitudes to capture trails from the moons in different sets of CCD columns. 2. Collect a sequence of low compression color frames spanning more than one full rotation. The goal being to allow wrap around linkage for FOV measurement to be performed with more stars (and away from the first frame which seems to have a higher noise level). Ideally, collect a series of these, each starting at a different random rotation angle. Thanks, Brian Swift |
|
|
Sep 25 2017, 04:14 PM
Post
#5
|
|
Senior Member Group: Members Posts: 2542 Joined: 13-September 05 Member No.: 497 |
I noticed what appear to be changes in compression artifacts between datatakes without an indication of a change in the .LBL file. For example, between JNCE_2016026_00C00063_V01 and JNCE_2016026_00C00064_V01. Could you comment on that? A visual example of what you are reacting to would be helpful. Without looking at these specific images, we've observed an effect where as the sensor warms up during operation, the dark level in the images interacts with the companding table in such a way as to (paradoxically) make the images less noisy, which changes the behavior of the lossy compressor. Unfortunately, the PDS archive product wasn't defined with a field to record what the actual compression factor was (that is, we don't record how big the original downlink file was), which would give some indication of what level of compression artifact to expect. QUOTE I also wonder if there are opportunities for non-standard imaging around apojove At the moment Junocam is turned off except near perijove, and the time near perijove is fully subscribed with images of the planet. With regard to calibration, my philosophy is to try to extract all the information possible from images that we already have before taking new images. There were a few instances in cruise where the TDI was commanded assuming the spacecraft was spinning at 1 RPM and it was really spinning at 2 RPM, and these images have the kinds of streaks you're describing. We just ignored them when we were doing our calibration, but maybe they have some utility. There are many, many images taken all the way around the orbit on orbit 1 of the moons with no TDI, and that's a good source of geometric information that we are in the early stages of looking at. Taking long exposures without TDI is outside the parameters that the instrument was designed to work within. It might be possible to command this, but obviously you can't take contiguous frames around a spin so you'd be taking images of somewhat random star fields. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Lo-Fi Version | Time is now: 22nd September 2024 - 10:03 AM |
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. |