Juno perijove 5, March 27, 2017 Options

[Sean]

Thank you Gerald. 1.7GB isn't that big!

Here is a still from your animation that I have started to process ...



thanks for sharing your work.

[mcaplinger]

Youtube upload of Perijove-05 animation completed.

This is really very promising. A couple of hopefully constructive criticisms:

1 ) you might consider cross-fading between images instead of cutting. There's at least one place where the cutting leaves you with a disorienting black image, I assume because the image coverage hasn't caught up to the spacecraft position.

2) your processing has become quite excellent except for the color. I'm not sure what's going on with the color but I don't think Jupiter is ever that green. Our missionjuno processing just does an auto white-balance after delambertianing and often leaves blue artifacts near the limb and terminator, but not the overall strong blue-green cast.

[scalbers]

The bluish-green can be of at least two reasons:
- Jupiter's haze appears to be bluish, especially when seen from acute angles, and near the poles.
- Some portions of some of the images are saturated in the red filter band, resulting in a cast to the complementary color, i.e. greenish-bluish. This risk has been taken, in order to obtain better S/N.

I recall some discussion about a greenish cast showing up in the Earth flyby images. Perhaps the red band was saturated there also? Unsure if the haze would have been a factor in this case. Would be interesting to model the expected color of Jupiter's haze and clouds with a scattering code.

Maybe this would be kind of drastic, though I wonder if reducing the color saturation in areas where the red is saturated on the bright end would help? Would this help get a better color balance in low intensity areas? Perhaps this is the S/N tradeoff being mentioned. Indeed the bright clouds should be a good white reference, at least near the nadir if the sun is reasonably high up. It is a challenge to maintain a good color balance with strong contrast enhancement, so perhaps a version with less contrast and more accurate hues would be interesting as well.

[mcaplinger]

Perhaps the red band was saturated there also?

AFAIK any saturation is only happening near the limb in some of the images. Even the nadir portions of these images are greenish in many cases.

There is probably a greenish/yellowish cast to images that have no color correction applied. We've reported the band correction factors in the PDS products but I've never actually validated those so if there's still some residual artifact I wouldn't be surprised. As I say, we're using a simple auto white balance which seems to work all right for Jupiter.

[Gerald]

This is really very promising. A couple of hopefully constructive criticisms:

Thanks! The list of basic image processing components I've been planning since months or even years is shrinking gradually. So, I'm going to be open for suggestions, and if it's just for prioritizing my scheduled tasks.

1 ) you might consider cross-fading between images instead of cutting.

I've an older version of code which blends renditions of two images directly from the raws, but didn't yet find time to adjust this code to the changes I've made for a single raw. I may entirely replace this code by just blending two overlapping sequences.
The decision to cutting has just been a matter of available time. I'll consider your point in my priorities.

There's at least one place where the cutting leaves you with a disorienting black image, I assume because the image coverage hasn't caught up to the spacecraft position.

Yes, that's the main reason. I just guessed the latitude coverage of each image with respect to time. Adding some more frames of #105 before starting #106 would have reduced this effect. I've also changed the software during rendition due to visible numerical jiggering effects and performance aspects, but intruduced a flaw, and another numerical difference between the two program versions. This led to different exposure and illumination adjustment. Eventually the movie became less smooth as it could have been. But rendering it anew would have taken another week, and I fully understood the root cause only lately.
I'm expecting these effects and difficulties to be absent or solved in my scheduled PJ06 flyby movie, since the accoring flaws are fixed now, and we have better latitude coverage.

2) your processing has become quite excellent except for the color. I'm not sure what's going on with the color but I don't think Jupiter is ever that green. Our missionjuno processing just does an auto white-balance after delambertianing and often leaves blue artifacts near the limb and terminator, but not the overall strong blue-green cast.

For this sequence, I didn't auto white-balance, but used your lab values (hopefully corrrectly). The stills for the movie are gamma-stetched with gamma=8 with respect to square-root encoding, hence the 4th power of illumination-adjusted radiometric values. This might enhance a subtle bluish cast to an obvious blue or blue-green hue. Besides this, some portions of some of the images may be saturated in the red band, leading to loss of red, and hence to a green-blue hue. I didn't try to correct saturated color channels. I'm strongly considering, that Jupiter's haze is mostly bluish. This shows up near the limb, near the terminator, and overall within the polar haze disks. I hesitate to adjust color weights by expections what a color of an unknown target should be. Analysing the optical properties of the haze is on my list. (We may discuss this in the context of the talk(s) I'm going to prepare for Riga.)

[Gerald]

I recall some discussion about a greenish cast showing up in the Earth flyby images.

These renditions haven't been properly decompanded, nor weighted according to lab data.
I didn't yet render the EFBs with the best available technique. May be I should put this on my list.

[Bjorn Jonsson]

Planetary colors are a complicated subject and I'm not surprised to see automatic processing that includes 'delamberting' sometimes resulting in strange colors.

What I usually do when I am processing the Juno Jupiter images without removing illumination effects is to multiply green by 1.12 and blue by 2.3 after decompanding. These values are empirical and represent a weighted average from three different methods to color correct the images:

(1) Simply adjusting the color of a global image until it looks 'right' (zones get whitish etc.).
(2) Measuring the color of a bright zone in a higher-res image and then correcting the color to make the zone roughly white (maybe slightly yellowish).
(3) Determining Jupiter's global color from a visible light spectrum and then making the average color of a global image from Juno similar. Here I attempted to account for the fact that the Juno global images show Jupiter from a vantage point that is very different from Earth-based images but did so in a preliminary way and need to do this more carefully.

When I remove global illumination effects (which I do using a modified Lommel-Seeliger function - it works better than Lambert) I select a well lit and fairly big patch in the image that is not too close to the limb. I then compare the color of the patch to the same patch in an image where illumination effects have not been removed. This results in multipliers for all three color channels that I apply to the image. I do this more or less manually.

[Gerald]

For the animation and PJ06 images, I didn't use a documented illumination model, but rougly speaking, it's somewhere between the Lambert and Lommel-Seeliger models. It's a function of incidence and emission angle with some intentional remaining illumination effect for better 3D appearance. It's derived from an averaged brightenss map as a function of incidence and emission angles, and some fine tuning on the basis of PJ05 images.
Thus far, I didn't yet model the dependency of the function from light wavelength. But I've implemented the infrastructure to do so in the near future. This lack of color adjustment to emission angles leads to a bluish cast in much of the animation, since most of the close-up sequence is derived from portions of the original images with acute emission angles, and without adjusting e.g. for Rayleigh scattering. I'm intending to do this in an automated way as soon as analysis and implementation are completed. I think, that it will take another several weeks, so it won't yet be applied to the first version of PJ06 animation, at least not yet fully. I'm expecting spectral effects of scattering being dependent on local atmospheric properties, and I'll try to take this into acount, where sufficient data is available.
For animations with up to several thousands of frames, I don't even try to do this manually, but work immediatly towards an automated solution, despite taking a little longer for the first results.

[Sean]

Some processed stills from Gerald's Perijove 05 animation...







...noticed these clouds sneaking by lower left ...

[Sean]

I processed Gerald's work again for this video...

[Sean]

PJ05_110 via Gerald

[Sean]

PJ05_anim_1369 processed frame from Gerald's animation

[Sean]

More from Gerald's PJ05 animation...




And a 4k wallpaper of the same...

[Gerald]

May be, we should consider a real-time animation with Juno spinning at 2 r.p.m., for PJ7, or an earlier test run?
For this week, however, my timetable is full already with several issues to fix, and scheduled products.

[Sean]

Ha, you read my mind Gerald...already working on it.