Juno Perijove 35 - Jupiter, July 21, 2021 Options

[mcaplinger]

First group of images, including Ganymede, now on missionjuno. More to follow.

[Bjorn Jonsson]

Is anyone else getting very large values that must be added to the START_TIME of the PJ35 Jupiter images to get correct limb positions? Instead of the value 61.88 msec (+/- possible jitter) I apparently need to add something like 120 msec. This is *much* larger than I have ever seen before. I have checked and double checked everything for two images (pj35_55 and pj35_71) without finding anything wrong in what I'm doing. I downloaded the new version of the SPK kernel juno_pred_orbit.bsp that was released today - it didn't result in any significant changes. I also tried running one of the PJ34 images through my processing pipeline but the results were correct/normal so on my end this is something specific to PJ35.

Either I'm messing something up or there are unusually large errors in one or more kernel files released following PJ35.

[Brian Swift]

Is anyone else getting very large values that must be added to the START_TIME of the PJ35 Jupiter images to get correct limb positions?

My "quick" limb fits look OK to me.

[Brian Swift]

So I wonder if this is a daytime lightning flash in P35_53 red filter.
Crop of processed Image:


Crop of raw:

[mcaplinger]

Either I'm messing something up or there are unusually large errors in one or more kernel files released following PJ35.

Not saying this is your issue, but I'll note that any use of a C kernel relies on having an up-to-date SCLK-SCET kernel, even if you're not making any explicit use of SCLK values otherwise. I've been burned by this several times.

[Bjorn Jonsson]

Not saying this is your issue, but I'll note that any use of a C kernel relies on having an up-to-date SCLK-SCET kernel, even if you're not making any explicit use of SCLK values otherwise. I've been burned by this several times.

In this particular case this was not my issue but this is something familiar. I always check for this if I get weird results.

My "quick" limb fits look OK to me.

Are these numbers error estimates from limb fits? I also get good/normal results from limb fits once I add ~120 msecs to START_TIME. The resulting processed images also look normal (e.g. nothing strange at the limb and no color channel alignment issues). What I'm suspicious about is the value 120 msecs which is unusually large. Which value are you adding to START_TIME for e.g. image PJ35_71?

[mcaplinger]

What I'm suspicious about is the value 120 msecs which is unusually large. Which value are you adding to START_TIME for e.g. image PJ35_71?

What kernels are you using? I'm seeing an offset of about 30 msec for that image using spk_pre_210607_211016_210712_otm35_p.bsp and juno_sc_rec_210720_210721_v01.bc

[Brian Swift]

Are these numbers error estimates from limb fits? ... Which value are you adding to START_TIME for e.g. image PJ35_71?

The values are my additive start time adjustments in seconds. So, for PJ35_71 I'm adding -27ms to start time.
Cavet: this is using my camera model so there may be a small bias relative the standard model.

But the the numbers show there is no excessive time shift on the order of the 120ms you are experiencing.

SPICE kernels I'm using:

CODE

                       '$JK/lsk/naif0012.tls'
                       '$JK/pck/pck00010.tpc'
                       '$JK/sclk/JNO_SCLKSCET.00117.tsc'
                       '$JK/fk/juno_v12.tf'
                       '$JK/ik/juno_junocam_v03.ti'
                       '$JK/spk/de440s.bsp'
                       '$JK/spk/jup363.bsp'
                       '$JK/spk/juno_struct_v04.bsp'
                       '$JK/spk/juno_pred_orbit.bsp'
                       '$JK/spk/spk_rec_131005_131014_131101.bsp'
                       '$JK/spk/juno_rec_orbit.bsp'
                       '$JK/ck/juno_sc_rec_210720_210721_v01.bc'

[Bjorn Jonsson]

Thanks to Brian and Mike for the information above. Should be sufficient for me to eventually determine what's going on. Very weird since everything seems normal for PJ34 and also earlier perijoves. In particular everything works perfectly where IMG/LBL files (and therefore accurate START_TIMEs) are available.

What kernels are you using? I'm seeing an offset of about 30 msec for that image using spk_pre_210607_211016_210712_otm35_p.bsp and juno_sc_rec_210720_210721_v01.bc

I was using juno_pred_orbit.bsp. Using spk_pre_210607_211016_210712_otm35_p.bsp instead resulted in only a small change (the difference in spacecraft position is just a few hundred meters for the image I tested).

In the meantime I decided to proceed with my processing of the PJ35 images and not wait until I've found exactly what's happening. Should be OK since this strange problem has no significant effect on the resulting processed images. This is a part of image PJ35_71 in an approximately true color/contrast version and an enhanced version:



This is an interesting image since a lot of spots of various sizes, colors and shapes are visible in a relatively small area. The biggest spot is Oval BA.

[Bjorn Jonsson]

This is a part of image PJ35_55 in approximately true color/contrast and enhanced versions:



BTW I have noticed that the images from recent perijoves are probably slightly redder than earlier images. I suspect the reason might be a lower amount of scattered light in the images due to a different viewing/illumination geometry (or possibly the scattered light distribution is different now). Bad bias correction or bad flat fielding is a possibility I have eliminated. Another possibility is that the camera sensitivity and/or filter transmission has changed but I think a lower/different amount of scattered light is more likely.

Because of this I changed the color correction multipliers when processing the PJ35 images, in effect brightening green by ~4% and blue by ~6% relative to the values I have been using for recent perijoves. This correction is preliminary and may need to be increased.

[Brian Swift]

BTW I have noticed that the images from recent perijoves are probably slightly redder than earlier images. I suspect the reason might be a lower amount of scattered light in the images due to a different viewing/illumination geometry (or possibly the scattered light distribution is different now).

By "scattered light" do you mean light scattering in the Jupiter's atmosphere, or light scattering within the camera sensor area?

[Bjorn Jonsson]

By "scattered light" do you mean light scattering in the Jupiter's atmosphere, or light scattering within the camera sensor area?

The latter.

[Bjorn Jonsson]

Here is an example of the color change I'm seeing from PJ20 to PJ35. The processing is identical for these two images. I checked the processing pipeline and can't see anything there that explains this difference so I'm pretty sure this is not a bug in my processing pipeline. In particular, the color multipliers are identical in these two cases.



In addition, at a quick glance the color I get at PJ27 is roughly intermediate between the PJ20 color and the PJ35 color.

[mcaplinger]

Here is an example of the color change I'm seeing from PJ20 to PJ35.

Probably a real change of Jupiter's. For example, https://britastro.org/node/25892 says

The EZ still has orange coloration, which has re-intensified to become darker and more vivid than it was a year ago.

[Bjorn Jonsson]

Probably a real change of Jupiter's. For example, https://britastro.org/node/25892 says

I seriously doubt this since AFAIK the color change mentioned there is confined to the Equatorial Zone but the reddening I'm seeing is global.

I have now verified with pretty good certainty that this color difference between PJ20 and PJ35 is present in the raw images. Assuming that these measurements from the raw PJ20 and PJ35 images are correct, a bug in my processing pipeline has been almost completely ruled out.

It would nevertheless be very interesting if someone (Brian maybe?) would process the PJ20_40 and PJ35_68 images and use identical color correction for PJ20_40 and PJ35_68. If the result is similar to mine (i.e. redder PJ35) it would completely rule out a bug in what I'm doing. A confirmed color change would be an interesting result regardless of what's causing it.