Juno Perijove 56, November 22, 2023 Options

[mcaplinger]

I have been making nice progress with the PJ56 images.

Thanks for doing this, Bjorn. Your results are impressive, and it makes me more optimistic that the PJ57 Io images will be useful.

You're certainly right that the blue channel is most badly affected.

[StargazeInWonder]

Beautiful images, despite the upstream glitches. It feels dramatic to have the first closest Io flybys occur just as the radiation is starting to have this degree of impact. Fingers crossed!

[Brian Swift]

You're certainly right that the blue channel is most badly affected.

I wonder if there could be value in acquiring blue-only higher-TDI images.
And also wonder, if red-green images were collected, could imaging cadence be increased to once per rotation (with the idea of having more images to average together to beat down random noise.)

[mcaplinger]

I wonder if there could be value in acquiring blue-only higher-TDI images.

If there was something important enough about the blue channel to make up for the costs of reduced imaging cadence, extra processing, etc, then sure.

And also wonder, if red-green images were collected, could imaging cadence be increased to once per rotation...

No, not for any image larger than 20 or so frames. You have to acquire all of the frames into JDEA DRAM and then transfer them all to the spacecraft before starting the next image.

(And I've just noticed an error in the Junocam paper -- it says "the data interface is a unidirectional three-signal RS-422 synchronous interface running at 20 Mbits/s" but the correct number is 4 Mbits/s.)

[Bjorn Jonsson]

The PJ56 images are good enough that I wouldn't make any changes in an attempt to get better images at PJ57 unless there was no risk (or an extremely small risk). And an obvious problem is that the satellite flybys happen very quickly which limits things like extra blue images at longer exposures etc.

The most obvious change to me is to maybe use a different companding function (or modify the current function) in an attempt to increase the dynamic range in the dark areas, especially in the blue channel. I haven't tried applying such functions to test data but an important consideration is the quality of the red images. Improving the quality of the blue images with a different companding function might be a bad idea if it results in worse red images. The PJ56 red images are actually quite good and therefore more important than the blue images.

Another idea is of course to completely omit the companding but that has a major drawback: Increased data storage requirements since the data would be 12 bits/pixel instead of 8. Data compression would probably also be less effective.

[mcaplinger]

Another idea is of course to completely omit the companding...

Alas, this isn't possible. The DRAM subsystem is designed around 8-bit pixels. In hindsight maybe we should have implemented a mode where one could get every other pixel in 12-bit form (there's something similar in CTX and LROC NAC) but obviously we weren't expecting this particular problem.

Similarly, if there's a better companding function that would improve on the current one given all of the limitations on the hardware (described upthread), we haven't been able to come up with it.

[StargazeInWonder]

It's a somewhat unknowable unknown, but the information value of three color filters as opposed to two may in principle be either great or virtually zero or anywhere in-between for a given target. If the color slopes of every surface unit is smooth, then two filters gives you basically the same information as three. Io, however, is maybe not such a target, and even if we suspected it to be so in older imagery, Io might always have a chromatic surprise somewhere, at some spatial resolution, that we haven't yet seen. The imagery from other recent flybys could probably give us some great hints about this.

[volcanopele]

Yeah, Io's spectrum has a significant break around blue so it is hard to get blue data back from just green and red, like maybe you could do for Europa and Ganymede to an extent. Three colors is best but yeah, too bad there isn't a lot of time to do various tests on different settings to see if messing with the companding could yield improve dynamic range in the resulting 8-bit data, a bit like the LUT and ADC settings tests we've done in the past on HiRISE.

[Brian Swift]

My current thought is that when taking images that are not "cadence constrained" (eg just Jupiter, not Io) would be to acquire "HDR" image sequences. Take a normal exposure image, followed as quickly as possible by a 3x or 4x longer exposure, and possibly followed by a 3rd even longer exposure. The idea being that the longer exposures will move the signal up out of the noise. And "exposure fusion" post processing could be used to recover useful imagery from the darker areas currently dominated by noise.

WRT companding. Probably want to eventually shift table (so bterm0 is about ~320 larger?), so lower ~100 companded values aren't going utilized.

[mcaplinger]

WRT companding. Probably want to eventually shift table (so bterm0 is about ~320 larger?), so lower ~100 companded values aren't going utilized.

The bterms are only 8 bits, unfortunately. We did not anticipate this particular problem.

[StargazeInWonder]

I just took Bjorn's approximately true color picture of Io from PJ 55, and tried synthesizing a blue channel from the green and red only. I subtracted half the red image from the green, then made that result about 1.5x brighter and used that as the blue. At a casual glance, this comes out looking almost indistinguishable from the original. So, unless the raw blue was used to help produce the green and/or red in that image, there's no doubt that we'll get something aesthetically great if we end up with only red and green data. But, it will be a fiction even if a pretty one and on the off-chance that there's actually an especially green or especially blue feature there (like a sulfur dioxide plume), it'll come out skewed.

I don't know what the chances are that the blue data would come back with some lines or pixels intact. As long as this image covers terrain seen from similar geometry in previous Juno imagery, there's the possibility of using that information to evaluate the veracity of such data in this imagery, and "ground truth" even the rare reliable blue pixel. There's potentially a detective story here to recover real color information at lower resolution.

[volcanopele]

tried that out with one of the PJ55 images and it does some weird things to areas that are greenish, like Chors Patera.

This product does a nice job of point out areas of spectral variation between red and green, but in areas where there isn't much, like near the equator, it makes the resulting product grey.

[Bjorn Jonsson]

Creating synthetic images using a linear combination of two colors doesn't work as well for Io as it does for e.g. the other Galileans or even Jupiter. Using violet and green to create synthetic blue images works fairly well using something like B=G*w+V*(1-w) (and maybe also multiplying this with a value close to 1 but not exactly 1). However, something comparable doesn't work well if you want synthetic red from IR756 and green Galileo images. I experimented with this years ago when I wanted a closer to true color version of the Galileo C21 global mosaic of Io. I ended up using a non-linear combination of IR756 and green with great results. This had one major drawback though: It worked well only for Io's anti-Jupiter's hemisphere. For the subjovian hemisphere a different formula was needed.

And now something different, a north polar map of Jupiter created from a mosaic of the PJ56_145 and PJ56_147 images. This is from the red channel only. The contrast has been increased.