I have no inside knowledge about this, but I suspect that the media reports have been somewhat modulated for dramatic effect.

IMU problems and subsequent use of all-stellar mode is pretty old news. See "Verification of Mars Odyssey All-Stellar Attitude Determination Ten Years After Launch", Gingerich et al, 2015, https://ieeexplore.ieee.org/document/7119001 (paywalled, but available at https://www.researchgate.net/publication/30...rs_after_launch )

The wrinkle for MAVEN was that they had some failures that required some ground-commanded manipulation of onboard redundancy. On previous missions, the transition to all-stellar could be done in a more leisurely and measured fashion.

Trendy, but I'm pretty skeptical based on results like https://www.mathworks.com/help/images/jpeg-...p-learning.html that this would really provide significant improvement. But it would sell more ML software

It's unclear to me how much of these pixel scale problems are due to compression and how much to companding and resulting color contouring. Obviously making color composites is going to exacerbate these problems, especially since the blue channel tends to be darker.

If someone is serious about looking at this, I'd be willing to provide some sample images. This 30-year-old compression software only runs on old SPARC machines and using it is a bit of a PITA even for me.

Can't do that without losing either coverage to the limb or some color bands or both. I'm not sure if the payoff is worth it but can raise this as well.



Isn't this more or less what we have been doing all along? (Subject to the data volume constraints and the fact that I think the value of the images near perijove are being overstated.)

I have no idea why https://github.com/kozkii/readmoc_nasa exists or who made it, but this is a mirror of the code that decompressed MOC-format files from our PDS archives for MGS (you could find it in the PDS archives if you looked for it). The Junocam code is essentially identical. Of course we run this ourselves to produce the decompressed products so this is only of academic interest.

All of the images that were lossy-compressed on PJ42 were set to a 5:1 compression target and more or less got that. So it's a tradeoff between getting images with this amount of compression or 2-3 times fewer images compressed lossless.

I'll bring up using lossless compression near perijove if possible at the next planning meeting.

No, onboard storage is the only constraint we think about.

All of the initial Io images on this pass were taken lossless, which probably increased the desire to compress subsequent images. If we take too much data, old stuff can be overwritten in some cases. Remember that we aren't specifying the compressed data volume, we are commanding an obscure parameter that is hard to map into a compressed data volume in advance. We have models of that mapping that by their nature have to err on the side of too much compression.

Images near perijove are often bland and end up overcompressing somewhat. That's my guess about what you are seeing.

The requant was decreased from 2.0 to 1.75 starting with image 65, which if anything should improve the quality a little.

Without looking at this in detail, I can only say that perceived image quality varies a lot depending on what the scene looks like and how the requantization happens to hit the DCT-space coefficients. Unlike JPEG, this compressor uses a fixed requant for all coefficients.

New paper on the DAVINCI mission: https://iopscience.iop.org/article/10.3847/PSJ/ac63c2/pdf

Well, you'd be wrong. And I grow quite weary of hearing that since I worked on that project for years and know exactly what happened. It was far more than a simple units mixup. [mods, feel free to delete this exchange as it is off-topic.]

I'm a fan of this person's launch renderings but this is not their best work. The color is way off for one thing.

Also, the rover can't move the RSM or arm while imaging.

Ceres is basically gray. If you're just messing around for fun, you can simply adjust the color channel brightness until the overall color is gray, and then change the contrast to see if you can bring up subtle color differences.

To really do science, you have to use and understand the radiometrically-calibrated image products.

Or you could just read https://www.researchgate.net/publication/31...g_Camera_Images

https://sbnarchive.psi.edu/pds3/dawn/fc/DWN...IS_20160815.PDF page 13-14.

All we do is call SPICE recpgr with the IAU spheroid flattening and report the "alt" value. https://naif.jpl.nasa.gov/pub/naif/toolkit_...e/recpgr_c.html

I believe Steve Ruff mentioned that in his most recent episode on Youtube. https://www.youtube.com/c/MarsGuy

Most people aren't authorized to discuss mission ops publicly because of project rules. In general, I think there would be a press release about a major outage or problem, but a minor one might well go unmentioned.

As of 3/25/2022, https://spaceflightnow.com/launch-schedule/ says 3Q 2022 and https://nssdc.gsfc.nasa.gov/nmc/spacecraft/...on?id=IM-1-NOVA says "mid to late 2022".

The April 2020 mission overview https://mepag.jpl.nasa.gov/meeting/2020-04/...erview%20V3.pdf clearly shows just one launch for the MAV and fetch rover. They've been holding the option open to split this in case of mass growth for a while, but it doesn't speak well to the maturity of the design IMHO.

Jan 2021 also shows one launch for fetch rover and MAV. https://mepag.jpl.nasa.gov/meeting/2021-01/...1_2021%20V5.pdf

Maybe we could just avoid all this churn and wait for the official site to be updated?

MSR has enough problems as it is. And I'm not sure what the point of sending another rover to the same site would be.

It's very unlikely that NASA would set an absolute drop-dead date in this fashion, so I think you should view this as funding until at least September.

It's not productive over-analyzing random media reports IMHO.

You can use SPICE-enhanced Cosmographia https://naif.jpl.nasa.gov/naif/cosmographia.html but I would call that neither easy nor convenient. There's a steep learning curve, especially with setting up the JSON files.

Not sure what you're suggesting. There is a 12-bit ADC in the camera but the "native bit depth" is effectively 8 bits because pixels always pass through a 12-to-8-bit companding table. The sensor saturation level is typically well below 255. The autoexposure algorithm is usually set to so that no more than 2-10% of an image's pixels exceed saturation, although sometimes the level and/or the fraction are tweaked depending on the scene (you can see these settings in the PDS product.)

If something is saturated on the raw images site and not saturated in PDS form, I can only blame the raw image stretching for that.

Agreed that "raw images" is something of a misnomer, but I'm not sure what you show has anything to do with JPEG. It's not uncommon for MCZ images to be sent with only lossless compression, which is as raw as it comes. I think the saturation problem you show is more due to the images having been stretched/contrast-enhanced. The vast majority of MCZ images are autoexposed and really shouldn't need to be stretched, and I have no idea what algorithm the raw image website is using.

Also, here's a mosaic of the radiation characterization image of Jupiter we take on each orbit through PJ34, linearized and normalized for solar distance.

I don't think that is definitive. All I can share is my conclusions slide presented at the last Junocam science team meeting (Oct 2021):

I think that product shows two different possible rover routes and no helicopter route at all.

I see no reason to doubt Karras' summary of how they plan to fly.

Here's the pointing I see for PJ40-05. Again, not great but doesn't seem out of family with typical errors.

I'm using spk_pre_211017_220412_220107_jm0400.bsp if that matters.