Juno Perijove 35 - Jupiter, July 21, 2021 |
Juno Perijove 35 - Jupiter, July 21, 2021 |
Jul 22 2021, 10:12 PM
Post
#1
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
First group of images, including Ganymede, now on missionjuno. More to follow.
-------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Jul 24 2021, 12:35 AM
Post
#2
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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. |
|
|
Jul 24 2021, 05:55 AM
Post
#3
|
|
Member Group: Members Posts: 403 Joined: 18-September 17 Member No.: 8250 |
|
|
|
Jul 24 2021, 06:03 AM
Post
#4
|
|
Member Group: Members Posts: 403 Joined: 18-September 17 Member No.: 8250 |
|
|
|
Jul 24 2021, 08:28 PM
Post
#5
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
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. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Jul 26 2021, 12:49 PM
Post
#6
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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. 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? |
|
|
Jul 26 2021, 03:27 PM
Post
#7
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
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 -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Jul 26 2021, 05:56 PM
Post
#8
|
|
Member Group: Members Posts: 403 Joined: 18-September 17 Member No.: 8250 |
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' |
|
|
Jul 26 2021, 10:51 PM
Post
#9
|
||
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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. |
|
|
||
Aug 2 2021, 12:15 AM
Post
#10
|
|||
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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. |
||
|
|||
Aug 2 2021, 07:08 AM
Post
#11
|
|
Member Group: Members Posts: 403 Joined: 18-September 17 Member No.: 8250 |
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? |
|
|
Aug 2 2021, 11:49 AM
Post
#12
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
|
|
|
Aug 4 2021, 03:20 PM
Post
#13
|
||
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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. |
|
|
||
Aug 5 2021, 08:21 PM
Post
#14
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
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 QUOTE The EZ still has orange coloration, which has re-intensified to become darker and more vivid than it was a year ago. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Aug 7 2021, 02:38 AM
Post
#15
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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. |
|
|
Lo-Fi Version | Time is now: 19th April 2024 - 10:28 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. |