Juno Perijove 56, November 22, 2023 Options

[mcaplinger]

There is plenty of literature that says that radiation damage of semiconductors can be annealed by heating in at least some cases.

The Junocam team is well aware of annealing. One might look carefully at the dark current in the past few marble movies for evidence of heating going back several orbits. (Dancing around the limits of what I can say here.)

I think that in doubt it's easier to cope with the thermal dark current than with severe radiation damage in case the heating is maintained during the flyby. If it's properly calibrated and reliable, the companding function could be offset by almost the level of the dark current. I know that we would see a lot more hot pixels. But that's something more or less systematic and reprodicible.

As far as we can tell, this issue is not related to dark current, which is a more gaussian noise source. And there are some limits to the amount of offset that can be put into the standard companding function due to bit sizes of registers. The images are unusable with any degree of heating. If we could reduce the temperature below the level it's at with no heating, we would do that and we believe it would help, but that's not really possible (recall that Junocam is inside a thermal-blanketed volume with just the lens looking out, and by design it's a stable not-too-hot, not-too-cold temperature in there. There's no active cooling.)

[stevesliva]

Mostly in response to Gerald.

I'm afield of my field, which is digital CMOS-- and this isn't even CMOS, it's a CCD AFAICT, like your 2nd paper-- but I did seem to gather that this was a really bad transient that affected pretty much all pixels, like accumulating charge in the substrate... that VSUB net on the chip's datasheet? I say "like" that because I know nothing about how the chip functions, even after looking at the data sheet. I'm just too far out of understanding the charge accumulation/xfer stuff to speculate on where the charge accumulates when it gets zapped. I have some small and partial understanding of that in CMOS, but not even CMOS imaging chips.

But the question I'm begging is... is this a presumed transient, so does hitting one of the various reset buttons in the system clear it, and what's the TAT? No answers required, just sharing my thoughts. Which are: I didn't jump to the conclusion that there's nonvolatile damage which must be annealed. I did jump to the conclusion that the (presumed) transient affected the whole system, not just some pixels. Could be wrong on all accounts. So from a system perspective, I thought, they'd be considering whether they can do curative cycles between imaging cycles. If there's time, and if it's worth the time.

[mcaplinger]

So from a system perspective, I thought, they'd be considering whether they can do curative cycles between imaging cycles.

So you're suggesting, basically, that we turn it off and back on again? Always reasonable tech support advice.

Unfortunately, whether that would help or not (and that's not clear), we can't do it for fear it will never start up again, as almost happened at PJ48. https://www.nasa.gov/missions/juno/nasas-ju...yby-of-jupiter/

If the images became completely unusable, we'll likely try this because there wouldn't be anything left to lose.

[added: To be clear, we don't think this is a transient, but we can't rule it out and in the abstract your suggestion is perfectly reasonable.]

[Brian Swift]

Posted following at https://www.missionjuno.swri.edu/junocam/discussion

From the Image Processing Welcome message at https://www.missionjuno.swri.edu/junocam/processing#Welcome
"
JunoCam is now showing the effects of that radiation on some of its parts. PJ56 images show a reduction in our dynamic range and an increase in background and noise. We invite citizen scientists to explore new ways to process these images to continue to bring out the beauty and mysteries of Jupiter and its moons.
"

Being part of the JunoCam image processing community, gaining a clearer understanding of the challenges would enable us to enhance our image processing techniques. Transparently sharing technical details, insights, and ongoing analysis from the project would boost our efficiency and improve our ability to devise effective workarounds.

The following image compares green channel PJ55_72 transformed with a very preliminary model of the image corruption issue with PJ56_191 raw data:

[mcaplinger]

Transparently sharing technical details, insights, and ongoing analysis from the project...

Did you have specific questions? I can't really do anything with a request this broad. And I think you are overestimating the value of the "ongoing analysis".

[Bjorn Jonsson]

Destriping the images seems to be trivial. I've had fairly good success using code based on a description of what the ISIS3 dstripe application does but I haven't tried pystripe yet (mentioned in the first post of this thread). The resulting red and green images don't look too bad. If the situation doesn't get worse before or during PJ57 the Io images are going to be very interesting despite this problem. A very quick-and-dirty destriped version from image PJ56_132 (can be improved, in particular I'm treating this as a single image instead of treating each framelet as an individual image):



A question for Mike (if you cannot answer it I understand): Is it safe for me to assume that the images got corrupted before companding or is it possible that they got corrupted during/after companding? I'm pretty sure it was before companding, meaning that I should decompand the images before I destripe and subtract the background but I want to be sure.

[mcaplinger]

Is it safe for me to assume that the images got corrupted before companding...

Yes. Unfortunately one of the major impacts of the offset becoming so large is that low signals are normally quantized more finely than high signals, but with a large offset this doesn't happen, and this degrades the SNR of dark parts of the scene (and would do so even if the noise wasn't present at all.)

In case it helps, the Junocam paper didn't provide as much information about the companding as it could have. This is all implicit in the lookup tables in the PDS product SIS, but just to be clear about how the hardware works, see below.

[siravan]

Is there any possibility of changing the exposure time? I don't know if JunoCam can handle shorter exposures, but if it can and the exposure time is reduced 4x, it may improve the SNR by a factor of ~2. Unfortunately, it will also increase the file size by 4x, which may not be possible or practical.

[mcaplinger]

Is there any possibility of changing the exposure time? I don't know if JunoCam can handle shorter exposures, but if it can and the exposure time is reduced 4x, it may improve the SNR by a factor of ~2. Unfortunately, it will also increase the file size by 4x, which may not be possible or practical.

I'm not following why you think using a shorter exposure time would help, or why it would increase the file size. Junocam is a pushframe imager, so we could reduce the exposure time as much as we wanted below the nominal 1 IFOV of blur at 3.2 msec. As far as we can tell, the noise and offset is largely independent of exposure time. You can see this for yourself by comparing the RGB, methane, and single-band lightning search images.

[Brian Swift]

Did you have specific questions? I can't really do anything with a request this broad. And I think you are overestimating the value of the "ongoing analysis".

What causes have been considered/analyzed and dismissed?
What are the current "most likely" causes?
Is the problem before, in, or after the ADC?
Is the companding implemented in HW circuit.
And while we're at it, as-flown schematics of instrument. Particularly, path from CCD to RAM (assuming problem is known to occur before bytes reach RAM.)

Is it just a coincidence that the noise (in de-companded values) is now ~256x larger (based on just looking at green channel from PJ55 and PJ56 "radiation trend monitoring" images.)

[mcaplinger]

What causes have been considered/analyzed and dismissed?

Bad bits out of ADC, basically everything after the CCD amplifier output.

What are the current "most likely" causes?

Radiation degradation of the CCD or possibly a bias voltage supply.

Is the problem before, in, or after the ADC?

Before.

Is the companding implemented in HW circuit.

Digital hardware, see above. The problem is not in companding.

And while we're at it, as-flown schematics of instrument.

I'm sure you're aware that this is not a very realistic request.

There's a nice block diagram in https://www.missionjuno.swri.edu/pub/e/down...each_Camera.pdf that should answer many questions. As time has gone by, we've had to be more and more conservative about the level of detail we've released in the open literature due to ITAR. That said, it's more or less the same as what's described in a little more detail in https://agupubs.onlinelibrary.wiley.com/doi...29/2008JE003315 for the MRO MARCI, sections 3.3.3 to 3.3.5. I can't share the specific part numbers of any of the ICs, though.

[Brian Swift]

I'm not following why you think using a shorter exposure time would help, or why it would increase the file size. Junocam is a pushframe imager, so we could reduce the exposure time as much as we wanted below the nominal 1 IFOV of blur at 3.2 msec. As far as we can tell, the noise and offset is largely independent of exposure time. You can see this for yourself by comparing the RGB, methane, and single-band lightning search images.

I think they are suggesting taking 4 images, each with 1/4 exposure time and averaging/summing them together to beat down noise (which as I recall would run into limitations either on a buffer size or how fast data can be moved to RAM).

the noise and offset is largely independent of exposure time

Since turning the instrument on and off ain't happening (for good reason). I was curious if there is any effect for either of:
1) taking several exposures as fast as possible (min exposure time, min INTERFRAME_DELAY) followed by a normal exposure.
2) taking a very long well-filling exposure, followed immediately by a normal exposure.

Of course I don't know if the instrument is capable of either of these operations.

ps. thanks for the responses to my questions. I am curious which specific ITAR sections are limiting you disclosure ability.

[mcaplinger]

I think they are suggesting taking 4 images, each with 1/4 exposure time and averaging/summing them together to beat down noise

It takes about 150 msec to read out a one-band image and about 255 msec for a three-band image, plus exposure time. So the typical visible exposure time of 3.2 or 6.4 msec is only a small fraction of that time. It might be barely possible to take one-band images at an interframe of say 160 msec, which would overlap downspin by more than 50%. That could help somewhat but it's a pretty big impact for not much return, it seems to me. 4X is just not possible.

1) taking several exposures as fast as possible (min exposure time, min INTERFRAME_DELAY) followed by a normal exposure.
2) taking a very long well-filling exposure, followed immediately by a normal exposure.

Both 1 and 2 would be limited in their cadence ("followed by/immediately" is no faster than the amount of time it takes to read the previous images out of DRAM to the s/c, many seconds). We've taken a range of exposure times (RGB/CH4/lightning) already and there seems to be very little difference in behavior with exposure time or from frame to frame at the standard interframe time. The fact that the offset occurs with images of black space suggests little dependence on signal level, we think it is a shift between the reset and video level coming out of the CCD.

I am curious which specific ITAR sections are limiting you disclosure ability.

I'm not a lawyer, I just know what they tell me I can and can't say. Some of this is now covered by EAR rather than ITAR, but it's not clear that it's helped. Maybe https://www.space.commerce.gov/regulations/...ol-regulations/ would have some useful background. If you argued that this is being overapplied, I wouldn't disagree with you, but it's above my pay grade.

[Bjorn Jonsson]

I have been making nice progress with the PJ56 images. This is image PJ56_140 at several different processing levels. The amount of processing increases from [a] to [d]. The images are illumination adjusted.




A short description of how the processing differs from [a] to [d]:

[a] Destriped using code based on a description of what the ISIS3 dstripe application does. I experimented with several different destripe parameters.
[b] Crude color correction in the purple areas.
[c] Green and blue channels modified to reduce noise. Here the green channel is a combination of a low pass filtered green image and high pass filtered red image.
The blue channel is a combination of a low pass filtered blue image and high pass filtered green image.
[d] Enhanced contrast and color saturation.

Keeping in mind what the original data looks like, I'm a bit surprised by the good quality of the red channel data here. However, the blue channel is almost useless in the darkest areas at right.

And for completeness, a version that is supposed to be an approximately true color/contrast image. However, the color is preliminary and probably significantly less accurate than in images from earlier orbits.

[Bjorn Jonsson]

Image PJ56_132:



The left image is an approximately true color/contrast version and the one at right is illumination-adjusted and contrast enhanced. North is up.

The red channel had some gaps that were filled using synthetic data created from the green channel. In addition, a narrow strip that contained only blue data was filled using data from image PJ56_135 (the quality of the PJ56_132 blue data was low so synthesizing acceptable red/green data from it was not possible). The resulting color composites have some spurious color variations that mainly manifest themselves as purplish or greenish areas. For obvious reasons, the color information is less reliable in the PJ56 images than in images from earlier perijoves, especially in dark areas.