Seriously, it's not trivial because of some timing limitations. We only took this image for Io, though I question if there was much point given the range. It does seem like Murphy's law always splits the image across the planet, we've had that problem since Earth flyby. Maybe there is some systematics in the spin phase we have never learned about.

Sure, it's easy. We only do it this way to irritate you personally.

Bjorn did this already also, upthread. I would prefer to do it for Europa, but don't have convenient tools to identify photobombing moons.

Unfortunately it's hard to correlate radiation effects in the sensor like this ("displacement damage dose") to overall radiation dose that damages glass ("total ionizing dose".)

We see a slow increase in warm pixels but it's been very gradual (also hard to control for orbit-to-orbit temperature variations.)

The filters are interference coatings on rad-hard fused silica substrates. If you look at figure 15 in the Junocam paper, we intentionally went to some lengths to use rad-hard glass for the first five elements, and the non-hard elements have a lot of titanium shielding around them. And the CCD (and filters) are enclosed in a copper-tungsten housing. https://www.missionjuno.swri.edu/pub/e/down...each_Camera.pdf

We have little idea of what actual total dose the instrument has seen, but we certainly weren't anticipating any gross optical effects like browning. And if we did see those, one would expect it to be gradual and cumulative, unless a single perijove pass got a large fraction of the overall total dose. I don't think there's any evidence of that, but I'm not really current on what the results of the radiation monitoring effort are.

Which Bjorn did back on post 23.

AFAIK (and strongly implied by the press release) the tube has been sealed and stored, so no reuse. The mechanism is complex enough without expecting it to be able to run backwards too.

Probably this was shadowing by the blades from the dustfall at the previous landing.

I believe, as I alluded to upthread, that this is a slightly out-of-date description, not exactly what they ended up flying. This paper describes what Honeybee called One Bit One Core (OBOC).

That said, it does capture the basic idea. There are three types of bits, one for solid rock cores, one for loose soil or regolith, and one for abrading (doesn't capture a sample). AFAIK, it's the first that resulted in the missing core.

Does the pile really look like it has enough volume to equal that of the hole?

I'm pretty sure that the final design is what Honeybee called "One Breakoff System One Core (OBSOC)" in https://www.hou.usra.edu/meetings/lpsc2014/pdf/1168.pdf if that helps.

They can be solid. I'm not sure how regolith is sampled, there may be multiple bit types [edit: yes, there are six coring bits, a regolith bit, and 2 abrading bits, see Mars 2020 Rover Adaptive Caching Assembly: Caching Martian Samples for Potential Earth Return, in the 45th AMS conference proceedings]. Unfortunately the SSR paper about the SCS is paywalled. See https://trs.jpl.nasa.gov/bitstream/handle/2...L%2317-1087.pdf for some discussion of the core breakoff mechanism (page 5.)

There are lots of references but many are old and I'm not sure what the system that flew ended up looking like.

Yes, certainly. And you can definitely see a color difference if you simply look at these two images in raw form.

The question is whether this is 1) a change in Junocam, 2) a change in Jupiter, or 3) a change in the illumination geometry. (I think we can rule out the illumination itself changing color.)

I vote for 2, and there are independent observations that suggest this is happening, at least for some areas.

One could perhaps look at the colors of the moons in various Junocam images over time to see if there has been a gross change in instrument response unrelated to the jovian atmosphere. Europa is probably the most color-neutral target.

Nope. The only files that use this value are the PDS-archived RDR files, which are all normalized for solar distance as described in the documentation.

The outreach map-projected RGB images on missionjuno have a lambertian shading correction applied and are then arbitrarily white-balanced, there is no explicit response function applied. The component map-projected images don't have the shading correction or the white balance, but are otherwise photometrically out of the camera (they have some blemish removal.)

They are simply white-balanced using a gray-world algorithm.

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

https://ntrs.nasa.gov/citations/19880057291

Unfortunately if there's an online version I don't know where.

google for "cmos black sun".

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

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.

Jupitershine? We were just trying it out since we had the available data volume.

We lost this battle for Mars back in 2001. https://www.msss.com/mgcwg/mgm/letter.txt

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

I suspect this is more complex than you think. Current NASA policy is described at https://sti.nasa.gov/submit-to-pubspace/ but this is still evolving and there's a 12-month lag. Many NASA center and JPL documents eventually show up on https://ntrs.nasa.gov/

Authors who wrote papers that are open-access at the journal paid that journal for the service out of their own funding streams, it's not required.

Ganymede is only about 120 pixels across at this distance in Junocam images. We're taking some, but they're not going to be comparable to PJ34's images.