PJ42_01. From upper left: Europa, Io, Jupiter. (Orientation, Io North Up)
Click to view attachment

A couple of images from yesterdays partial downlink:


Jupiter - PJ42-7


Jupiter - PJ42-10


Jupiter - PJ42-13

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


Jupiter - PJ42-26


Jupiter - PJ42-27


Jupiter - PJ42-28

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.

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.
Click to view attachment

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.

Bummer. Can't just lobby for more DSN time to get more data.
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.
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
Click to view attachment

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.

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

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.

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.

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

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.
Click to view attachment

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.

I was going to suggest blowing the cobwebs off the SPARC and processing PJ42_35 which is Huffman compressed, is taken only 2min following PJ42 _34 (which I used to show the banding in my earlier post), has same exposure, and most of FOV overlaps PJ42 _34. However, I then realized I could just render PJ42_35 from the viewpoint of PJ42_34. So this images shows a section of PJ42_34 (ICT compressed) with banding adjacent to the same area from PJ42_35 (Huffman). So the SPARC can continue to Rest In Peace.
Click to view attachment
My speculation is that the Huffman compression is preserving a "natural" dithering that encodes a gradual change between adjacent DN values, and the ICT compression removes that high-frequency dithering.

Was able to create a North-to-South overview using most of the RGB imagery. Skipped any that my pipeline borked the output mesh/UV mapping



Jupiter - Perijove 42

PJ42 Exaggerated Color/Contrast collection
Click to view attachment
Full Resolution version available at https://www.missionjuno.swri.edu/junocam/processing?id=13233

Very interesting discussion. As suggested in earlier posts here, I think it would be a very interesting and good idea to take at least one test image with lossless compression over the highly photogenic area near latitude ~40 deg north. This would be an image obtained near perijove - probably not the highest resolution image but close to it. The exact location should be selected to maximize the probability of imaging a photogenic, high contrast area with various cloud features visible. If I have understood everything correctly this would have to be done soon since perijove will be occurring over Jupiter's nightside only a few orbits from now.

In contrast, I doubt there is strong need for more images near perijove because even though everything is moving pretty fast there has always been nice overlap between adjacent images (the emission angle is not optimal for some areas though but there's always overlap).

I took a quick look at compression artifacts. This is a heavily processed example comparing PJ42_34 (lossy compression) and PJ42_35 (lossless) by rendering them using identical viewing geometry. This is comparable to what Brian did earlier.

Click to view attachment

Image 34 lacks many of the details visible in image 35 and has obvious artifacts that are very probably due to the compression - some very uniform areas and far less 'dithering-like' appearance. There are some differences because the emission angles in the source data differ for obvious reasons but I don't think this is the reason for any the artifacts. It is also obvious from the PJ42_34 image (and also obvious in Brian's image) that the 'color discontinuity' that was discussed in the PJ6 thread has now appeared again because the images show an area fairly close to the terminator.

Here is a different example of compression artifacts. This is a contrast stretch of a small part of the 34 and 35 raw images without any other processing (i.e. this is not decompanded):

Click to view attachment

Here image 34 does not show the same area as image 35 but the compression-related differences are nevertheless obvious. There are no completely uniform areas in image 35 whereas image 34 has some completely uniform areas.

Images 34 and 35 show a relatively low contrast area near the equator. I also took a look at image 28 which shows a high contrast area and was obtained near perijove (the resolution is ~2.5 km/pixel at the nadir). This image was obtained with lossy compression and unlike the 34/35 comparison, no image with lossless compression shows this area. Therefore a comparison to lossless data is not possible. Here is a contrast stretched crop from image 28:

Click to view attachment

Some 'contouring' is visible at various locations, e.g. lower right and upper left and more subtle in the dark, reddish/brownish spot at left. What's happening is more obvious when the color channels are examined separately:

Click to view attachment

The compression artifacts (I'm assuming the uniform areas are compression artifacts - this seems very likely but it is not completely certain) are relatively subtle in the red channel but very pronounced in the green and blue channel. I think it would be very interesting to know what a photogenic, high contrast area like the one in image PJ42_28 looks like at very high resolution without compression artifacts.

Interestingly, I have found that it *might* be possible to make these artifacts slightly less obvious by adding a small amount of noise to the raw image before decompanding. These experiments of mine are at a very early stage though so I don't know exactly how well this would work. A different amount of noise is probably needed for the different color channels. This plus the images above also implies that it might make sense to use different compression parameters for the different color channels (higher compression for red than for green/blue) but I would be *very* surprised if this was possible.

Thanks for the pointer to the 'color discontinuity' discussion. I noticed it in recent perijoves, but hadn't investigated, thinking it was probably just some natural haze.
While we're re-engineering the image data handling system ;-) another change could be different companding tables for each color (or at least for blue), and even crazier would be multiple "dithered" companding tables...

FWIW, I raised the possibility of doing this in today's PJ43 planning telecon, but we can't do it for PJ43 because of data volume constraints from Io imaging. We will certainly consider it for PJ44.