Juno Perijove 42, May 23, 2022 Options

[Brian Swift]

PJ42_01. From upper left: Europa, Io, Jupiter. (Orientation, Io North Up)

[Kevin Gill]

A couple of images from yesterdays partial downlink:


Jupiter - PJ42-7


Jupiter - PJ42-10


Jupiter - PJ42-13

[Kevin Gill]

Some breathtaking views from Jupiter this perijove! Go Juno! Here's three more:


Jupiter - PJ42-26


Jupiter - PJ42-27


Jupiter - PJ42-28

[Brian Swift]

Mike, do the JunoCam INTEGER COSINE TRANSFORM compression rate/quality parameters change between images?
Compression seems more noticeable in PJ42_24 and later, and especially with PJ42_34.

[mcaplinger]

Mike, do the JunoCam INTEGER COSINE TRANSFORM compression rate/quality parameters change between images?
Compression seems more noticeable in PJ42_24 and later, and especially with PJ42_34.

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.

[Brian Swift]

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.

Thanks. Currently 36 is the last available at missionjuno.

Is it the case that DSN time (and not onboard storage) is the driving constraint on downlinked data volume?

Here is central part of PJ42_34, which caught my eye as being particularly blocky.

[mcaplinger]

Is it the case that DSN time (and not onboard storage) is the driving constraint on downlinked data volume?

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.

[Brian Swift]

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

Bummer. Can't just lobby for more DSN time to get more data.

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.

Do you have any pointers to algorithm description docs or a software implementation of the ICT used for JunoCam?
Net searching gives some JPL papers from the '90s.

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

Yes, my earlier image showing the artifacts is fairly bland, and the visible "steps" are just 1DN changes in the raw data.
However, as Björn mentioned on twitter, perijove is now occurring over more interesting areas.

Below is PJ42_30 (the image with lowest altitude (3262.3km)), which has a maximum resolution at boresight of 2.3 km/pixel

[mcaplinger]

Do you have any pointers to algorithm description docs or a software implementation of the ICT used for JunoCam?

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.

[Brian Swift]

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.

Thanks. Odd coincidence that it was created only 3 days ago. Also the README.md has a now-defunct link to a MSSS software page (that didn't get fully internet-archived). But I also see the software in PDS at https://pds.nasa.gov/data/mgs-m-moc-na_wa-2..._1121/software/

I assume the compression software is MSSS proprietary.

If I were an enthusiastic youngster with time on my hands, and access to JunoCam ICT compression and decompression software, I might compress and decompress all the losslessly downlinked images to train up a neural net to recover original data from ICT compressed downlinks.

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.

From the conflicting requirements department , I'd also like a couple more images at perijove captured with less time between them (eg 90 or 60 seconds instead of 120) since everything is moving by so fast.

[owlsyme]

Some breathtaking views from Jupiter this perijove! Go Juno! Here's three more:

Those are indeed amazing, so much detail in the clouds!

I hope that someday there will be balloons flying through the atmosphere taking movies, and we'll be around to see them.

[Floyd]

Brian's comment "I'd also like a couple more images at perijove captured with less time between them (eg 90 or 60 seconds instead of 120) since everything is moving by so fast" got me thinking about the timing of the images. On its basically elliptical path around Jupiter, on approach, the angle between the orbital velocity vector and the vector to the center of Jupiter starts as some minimum values (say 15 degrees), increases to 90 at closest approach, goes to some maximum (say 165 degrees) and back to 90 degrees at the apogee. One way of taking images would be to take one as the vector changes a few degrees--say 5 degrees. Close to perigee you would take images at 60, 65, 70, 75, 80, 85, 90, 95, 100, 105, 110, 115, 120 degrees.

mcaplinger, has this type of image timing been considered? I know there are a lots of tradeoffs and constraints, like minimum time between images.

[mcaplinger]

I'd also like a couple more images at perijove captured with less time between them (eg 90 or 60 seconds instead of 120) since everything is moving by so fast.

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.

mcaplinger, has this type of image timing been considered?

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.)

[Brian Swift]

PJ42 Interesting Swirly Clouds near North Pole (Exaggerated Color/Contrast), movement of cloud structure over 11 minutes as Juno spacecraft passed by at a distance ranging from 29237 km to 17503 km.

[mcaplinger]

If I were an enthusiastic youngster with time on my hands, and access to JunoCam ICT compression and decompression software, I might compress and decompress all the losslessly downlinked images to train up a neural net to recover original data from ICT compressed downlinks.

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.