Juno Perijove 40, February 25, 2022 Options

[Brian Swift]

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

[Brian Swift]

PJ40 Images, Exaggerated Color/Contrast


Full resolution available at https://www.missionjuno.swri.edu/junocam/processing?id=12680

[Bjorn Jonsson]

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.

[StargazeInWonder]

Was the reddening noticed in the recent Europa images? That would definitely speak to whether it is specific to Jupiter or not.

[Bjorn Jonsson]

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.

[mcaplinger]

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):

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

[mcaplinger]

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.

[Bjorn Jonsson]

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).

[Bjorn Jonsson]

Image PJ40_38, approximately true color/contrast and enhanced:

[Bjorn Jonsson]

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:

[mcaplinger]

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

[Bjorn Jonsson]

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.

[volcanopele]

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 )

[Bjorn Jonsson]

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.

[StargazeInWonder]

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?