Juno Perijove 40, February 25, 2022 |
Juno Perijove 40, February 25, 2022 |
Mar 4 2022, 01:31 AM
Post
#16
|
||
Member Group: Members Posts: 406 Joined: 18-September 17 Member No.: 8250 |
Monolith Herd Stampeding Across Jovian Plains
Animation of JunoCam images from perijove 40 on 2022-02-25 showing Ganymede’s shadow moving across Jupiter’s clouds. While the Juno spacecraft was moving through its orbit during the 1.5 hours over which raw data was collected, these images are rendered from a single point of view in the orbit to hold Jupiter fixed in the video frame. Full Resolution versions at https://vimeo.com/684456354 and https://youtu.be/wA9jliQZSdI |
|
|
||
Mar 4 2022, 05:47 PM
Post
#17
|
||
Member Group: Members Posts: 406 Joined: 18-September 17 Member No.: 8250 |
PJ40 Images, Exaggerated Color/Contrast
Full resolution available at https://www.missionjuno.swri.edu/junocam/processing?id=12680 |
|
|
||
Mar 6 2022, 02:57 PM
Post
#18
|
||||
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
This is processed from image PJ40_33. Approximately true color/contrast and enhanced versions:
The JunoCam images continue to get redder (this change was discussed in an earlier thread here last year). I have mainly been using the South Tropical Zone (STrZ) as 'reference' when monitoring the color. This is an updated plot showing the B/R ratio in the STrZ. As earlier, the B/R=1 point is arbitrary. Because of the reddening I recently changed the color correction I use in my processing pipeline. For PJ40 I multiply R/G/B with 1, 1.306 and 3.275, respectively. These values are preliminary and might change slightly. |
|||
|
||||
Mar 6 2022, 09:17 PM
Post
#19
|
|
Member Group: Members Posts: 228 Joined: 14-January 22 Member No.: 9140 |
Was the reddening noticed in the recent Europa images? That would definitely speak to whether it is specific to Jupiter or not.
|
|
|
Mar 6 2022, 11:03 PM
Post
#20
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
This color change is specific to JunoCam, it is not Jupiter's color that is changing. This can be verified by checking images of Jupiter obtained by e.g. Hubble.
|
|
|
Mar 6 2022, 11:18 PM
Post
#21
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
This color change is specific to JunoCam... I don't think that is definitive. All I can share is my conclusions slide presented at the last Junocam science team meeting (Oct 2021): QUOTE Something seems to be happening to the color, but it’s not clear if it’s intrinsic to the instrument or not If it were radiation-induced, that would not be unexpected (remember, Junocam was only designed to last until orbit 8) but the observed effect doesn’t match any expected morphology very well As always, caution is warranted for any science application that depends on precise knowledge of instrument photometric response – don’t go off and write papers asserting that Jupiter is changing color just on the basis of Junocam imaging -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Mar 6 2022, 11:39 PM
Post
#22
|
||
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
Also, here's a mosaic of the radiation characterization image of Jupiter we take on each orbit through PJ34, linearized and normalized for solar distance.
-------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
||
Mar 7 2022, 10:38 PM
Post
#23
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
Thanks - this is the best overview of the reddening I have seen.
This color change is specific to JunoCam... I don't think that is definitive. All I can share is my conclusions slide presented at the last Junocam science team meeting (Oct 2021): Yes, my post wasn't clear enough. I was referring to JunoCam images, regardless of whether the color change is intrinsic to the instrument or due to e.g. scattered light (or both). In this context I find it interesting that in the plot I posted the point for perijove 38 is an outlier and this happens to be the perijove when the spacecraft was oriented differently from other recent perijoves. Which means that the illumination geometry is different for the spacecraft components that might be scattering small amounts of light into JunoCam. The only really clear thing IMHO is that only a small part of the reddening (or none at all) can be due to a global color change on Jupiter since e.g. Hubble images I have looked at show no obvious color change (I can't rule out a small color change though but if present it's much smaller than the change in the JunoCam images). |
|
|
Mar 9 2022, 10:50 PM
Post
#24
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
|
|
|
Apr 11 2022, 02:30 PM
Post
#25
|
|||
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
Regarding the discussion earlier on the unusually large value I had to add to the START_TIME to get correct limb fits (Kevin had similar problems): Using the reconstructed SPK kernel (instead of the predict kernel released shortly after PJ40) didn't result in any significant change.
It might be of interest that I have noticed that for PJ40, Juno's distance to the closest point on Jupiter I get by computing it from the SPICE kernels is significantly larger than the SPACECRAFT_ALTITUDE value in the *-Metadata.json files released with the images. The difference is typically ~500 km. This is rather large but comparable values have been seen for a few earlier perijoves so I don't think it has anything to do with the limb fit issues. Finally on a different note, this is processed from image PJ40_22: |
||
|
|||
Apr 11 2022, 04:02 PM
Post
#26
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
It might be of interest that I have noticed that for PJ40, Juno's distance to the closest point on Jupiter I get by computing it from the SPICE kernels is significantly larger than the SPACECRAFT_ALTITUDE value in the *-Metadata.json files released with the images. All we do is call SPICE recpgr with the IAU spheroid flattening and report the "alt" value. https://naif.jpl.nasa.gov/pub/naif/toolkit_...e/recpgr_c.html -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Apr 11 2022, 09:39 PM
Post
#27
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
I'm using subpnt_c to get the distance to the closest point on the target body using the value "Near point: ellipsoid" for the first parameter. This call isn't really a part of my main processing pipeline, I'm using it only because I was curious to know the distance to the closest point. I may take a look at this issue later but I should be getting an obvious limb fit 'mismatch' if the spacecraft position (or Jupiter distance) really is incorrect, i.e. if the location of the 'upper' limb is correct the 'lower' limb would have a large error (or vice versa). However, everything looks normal there.
|
|
|
Apr 11 2022, 10:02 PM
Post
#28
|
|
Senior Member Group: Moderator Posts: 3233 Joined: 11-February 04 From: Tucson, AZ Member No.: 23 |
I guess this could quickly turn into a discussion of using the SPICE toolkit, but in my python scripts using spicypy, here is my code for calculating altitude (which I think is just lifted from the spicypy tutorial:
CODE method = 'Intercept/Ellipsoid'
target = 'IO' tarfrm = 'IAU_IO' abcorr = 'LT+S' # obtain cartesian coordinates for sub-spacecraft point at the time of closest approach [spoint, trgepc, srfvec] = spiceypy.subpnt( method, target, et, tarfrm, abcorr, scname ) # compute altitude alt = spiceypy.vnorm( srfvec ) -------------------- &@^^!% Jim! I'm a geologist, not a physicist!
The Gish Bar Times - A Blog all about Jupiter's Moon Io |
|
|
Jul 5 2023, 11:33 PM
Post
#29
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
I'm reviving this thread because recently I was processing some PJ40 data and I think that at last I now know what was happening here:
Additional info: I'm getting weird results for the Jupiter images as well. For image PJ40_11 I need to add something like 250 msec to the start/stop times to get correct limb fits. This is far bigger than I have seen before (the highest I've seen is ~100 msec IIRC). This was followed by fairly extensive discussion; I wasn't the only one running into weird issues. The reason this happened seems to have been the clock kernel I was using. I was using the JNO_SCLKSCET.00127.tsc file released a day after PJ40. A reconstructed CK kernel was released at a similar time but apparently a different clock kernel is needed together with the CK kernel. Using JNO_SCLKSCET.00126.tsc or JNO_SCLKSCET.00125.tsc results in a far smaller error, especially the latter. However, the error is still rather large. Using JNO_SCLKSCET.00124.tsc results in a 'typical' error. The real problem now is that I haven't found any reliable way to determine which clock kernel I should use together with a particular CK file. Apparently the file dates cannot be used to determine this. The CK kernel contains a clock kernel name but that name is always juno.tsc so it is useless. For a long time I was assuming that using the file released around or immediately following a perijove was OK but clearly this is not the case as implied above. Usually it has not mattered exactly which file I used (typically the resulting difference when replacing a clock kernel was 1-2 pixels or less) but recently (the past 10-15 perijoves or so), it has become more common for this to make a large difference. Having to use trial and error to determine which clock kernel to use with the reconstructed CK kernel doesn't make sense to me. Does anyone know of a better or more reliable way to determine which clock kernel to use together with a particular reconstructed CK kernel? Using trial and error, it *usually* becomes fairly obvious which kernel to use but this is not always the case. |
|
|
Jul 6 2023, 01:07 AM
Post
#30
|
|
Member Group: Members Posts: 228 Joined: 14-January 22 Member No.: 9140 |
At the hazard of speculating when I have not gotten my hands dirty with this data, does this pertain to the influence that close passes with the Galileans have on the subsequent trajectory/orbit? That began about 20 PJs ago. Close passes to a third body in principle introduce accentuated unknowns in trajectories. Are the updates refinements based on information known only after each such encounter?
|
|
|
Lo-Fi Version | Time is now: 27th April 2024 - 06:19 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. |