Most significant/least significant part.

Floating point double precision is a clue. Pioneer 6 was run by NASA Ames, I'm not sure what computer types they were using (this was long before IEEE floating point standardization.)

Historically rovers haven't gotten names like this. The MER-B landing site was already named. https://en.wikipedia.org/wiki/List_of_extra...trial_memorials

Terminology: vignetting is a global shading across the field unrelated to the little bits of crud on the focal plane. https://en.wikipedia.org/wiki/Vignetting

Some diminutive seems inevitable. According to https://en.wikipedia.org/wiki/Rosalind_Franklin her family referred to her as "Ros".

The image below shows per-channel overlays of the limbs of Io and Jupiter as predicted by our best current model for PJ16-011, no timing adjustment other than our nominal recommended one. The Io limb is pretty close to dead on (maybe a pixel off in the red) and the Jupiter limb is clearly low relative to the observed limb by 4 pixels or so. So that does support the idea that what we see is higher than the limb defined by the IAU radii in the SPICE planetary constants file. Of course, the observed limb is not super-sharp so it's a judgement call about where it is exactly.

Interesting paper. It's surprising and disappointing to me that the solar array performance data remains unreleased.

Using which SPICE kernels? Always important to make sure you are using the best reconstructions, the right SCLK-SCET, leapseconds, etc.

Wish I could take credit for this, but AFAIK we didn't even intentionally command an image for this event, much less a specific spin phasing, so it's all random chance.

One does not simply "throw stuff" onto the PDS. https://pds-smallbodies.astro.umd.edu/data_...AP-01_R0_C0.pdf doesn't describe the schedule for the extended mission but Table 3 says the first delivery of Pluto encounter data took about 9 months from encounter.

OK. I don't find that discussion has enough technical detail to understand what the real issue is, but I'm probably being excessively pedantic as someone who wrote the flash software for the cameras. (Recall that the flash problems are on the rover side, the cameras still have as much flash as they always have.)

At any rate, if we were trying to limit memory usage we would use more JPEG, not less.

It's unrelated to the memory problems (whatever they are, I haven't heard the details and "lost chunks of memory" may not be accurate). If the downlink volume allows it, people would rather have the raw data than JPEG.

As I've said before, I've complained myself about the inappropriate use of JPEG on Bayer encoding to everyone who would listen, but it's not up to me obviously. Complaining about it here is not productive and probably a rule 2.6 violation.

Tweet is dated 8:47 PM 1/5/2019, which I assume is PST. That's 04:47 UT on 2019-006 which according to MarsJ24 is 11:12 LMST at Opportunity.

Wow, those are amazing!

Did Cassini use thumbnails? Maybe, I wasn't aware it did.

NH probably wasn't designed with a flyby of a small body with such uncertain centering in mind, I don't think they had so much of a problem at Pluto (but I could be mistaken.)

FWIW, I argued long and hard that thumbnails for MSL Mastcam were not worth implementing. In hindsight I was wrong, but the use case of ground-in-the-loop selective transmission doesn't end up getting used that often, and we had to work fairly hard to get the thumbnail products small enough to be cheaply downlinked. They are mostly useful just to show that a sequence executed as designed, but that's fairly expensive for what amounts to debugging messages (though one can amuse oneself by building mosaics of thumbnails while waiting for the full products, etc.)

Which missions are those?

Maybe they just didn't think of it or they couldn't make it fit in their FSW. There's a general bias to minimize work done on the space side even if work on the ground side is 10x harder.

We use thumbnails on MSL, obviously, but usually not to pick and choose what to send down once we see the thumbnails. Sometimes, not often.

Not having to have the ground in the loop to decide what to send down would be one reason. Especially when you're six light-hours away.

Mostly because none of us know as much about Io as Jason does. I spent several hours on Christmas looking at maps of Io and trying to figure it out without much luck.

What did you expect him to say? I'm sure it will be interesting, but I wouldn't read much into this.

I didn't have much to do with this press release.

If you read the Junocam image caption, it says "The image... was acquired at 12:20 (UTC) on Dec. 21, 2018. The Juno spacecraft was approximately 300,000 km from Io."

https://www-robotics.jpl.nasa.gov/publicati...Drift_final.pdf -- I expect that the Mission Clock would reset to zero if the power dropped below the maintenance level, but I'm not sure. It really doesn't matter for recovery as there are other sol-based timers that will be used. If they recover, resetting the clock should be simple.

The "flare" is a blooming artifact, ignore it.

Where's Jason Perry when you need him?

I think your processing may be filtering out an interesting aspect of the Io images, especially pj17-006.

Y'all may want to take a peek at the Io images just posted on missionjuno.

I don't think it does. I think the appropriate equation is 0.5 * density * area * windspeed^2 https://www.engineeringtoolbox.com/wind-load-d_1775.html