[X] My Assistant

[Brian Swift]

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

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

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