IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
Juno Perijove 42
Brian Swift
post May 24 2022, 05:56 AM
Post #1


Member
***

Group: Members
Posts: 289
Joined: 18-September 17
Member No.: 8250



PJ42_01. From upper left: Europa, Io, Jupiter. (Orientation, Io North Up)
Attached Image
Go to the top of the page
 
+Quote Post
Kevin Gill
post May 24 2022, 03:38 PM
Post #2


Member
***

Group: Members
Posts: 107
Joined: 22-July 14
Member No.: 7220



A couple of images from yesterdays partial downlink:


Jupiter - PJ42-7


Jupiter - PJ42-10


Jupiter - PJ42-13
Go to the top of the page
 
+Quote Post
Kevin Gill
post May 25 2022, 12:09 AM
Post #3


Member
***

Group: Members
Posts: 107
Joined: 22-July 14
Member No.: 7220



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


Jupiter - PJ42-26


Jupiter - PJ42-27


Jupiter - PJ42-28
Go to the top of the page
 
+Quote Post
Brian Swift
post May 27 2022, 05:42 PM
Post #4


Member
***

Group: Members
Posts: 289
Joined: 18-September 17
Member No.: 8250



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.
Go to the top of the page
 
+Quote Post
mcaplinger
post May 27 2022, 09:48 PM
Post #5


Senior Member
****

Group: Members
Posts: 2262
Joined: 13-September 05
Member No.: 497



QUOTE (Brian Swift @ May 27 2022, 09:42 AM) *
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.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post May 28 2022, 02:15 AM
Post #6


Member
***

Group: Members
Posts: 289
Joined: 18-September 17
Member No.: 8250



QUOTE (mcaplinger @ May 27 2022, 01:48 PM) *
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.
Attached Image
Go to the top of the page
 
+Quote Post
mcaplinger
post May 28 2022, 02:56 AM
Post #7


Senior Member
****

Group: Members
Posts: 2262
Joined: 13-September 05
Member No.: 497



QUOTE (Brian Swift @ May 27 2022, 06:15 PM) *
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.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post May 28 2022, 07:38 PM
Post #8


Member
***

Group: Members
Posts: 289
Joined: 18-September 17
Member No.: 8250



QUOTE (mcaplinger @ May 27 2022, 07:56 PM) *
No, onboard storage is the only constraint we think about.
Bummer. Can't just lobby for more DSN time to get more data.
QUOTE
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.
QUOTE
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
Attached Image

Go to the top of the page
 
+Quote Post
mcaplinger
post May 28 2022, 10:52 PM
Post #9


Senior Member
****

Group: Members
Posts: 2262
Joined: 13-September 05
Member No.: 497



QUOTE (Brian Swift @ May 28 2022, 12:38 PM) *
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.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post May 29 2022, 06:37 AM
Post #10


Member
***

Group: Members
Posts: 289
Joined: 18-September 17
Member No.: 8250



QUOTE (mcaplinger @ May 28 2022, 02:52 PM) *
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.
QUOTE
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 laugh.gif , 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.
Go to the top of the page
 
+Quote Post
owlsyme
post May 29 2022, 12:43 PM
Post #11


Newbie
*

Group: Members
Posts: 16
Joined: 23-July 15
From: Austin, TX
Member No.: 7615



QUOTE (Kevin Gill @ May 24 2022, 06:09 PM) *
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. smile.gif

Go to the top of the page
 
+Quote Post
Floyd
post May 29 2022, 04:27 PM
Post #12


Member
***

Group: Members
Posts: 872
Joined: 4-September 06
From: Boston
Member No.: 1102



QUOTE (Brian Swift @ May 29 2022, 01:37 AM) *

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.


--------------------
Go to the top of the page
 
+Quote Post
mcaplinger
post May 29 2022, 05:39 PM
Post #13


Senior Member
****

Group: Members
Posts: 2262
Joined: 13-September 05
Member No.: 497



QUOTE (Brian Swift @ May 28 2022, 10:37 PM) *
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.


QUOTE (Floyd @ May 29 2022, 08:27 AM) *
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.)


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post May 31 2022, 06:27 AM
Post #14


Member
***

Group: Members
Posts: 289
Joined: 18-September 17
Member No.: 8250



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.
Attached Image
Go to the top of the page
 
+Quote Post
mcaplinger
post May 31 2022, 03:33 PM
Post #15


Senior Member
****

Group: Members
Posts: 2262
Joined: 13-September 05
Member No.: 497



QUOTE (Brian Swift @ May 28 2022, 11:37 PM) *
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 smile.gif

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.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic

 



RSS Lo-Fi Version Time is now: 25th June 2022 - 07:06 AM
RULES AND GUIDELINES
Please read the Forum Rules and Guidelines before posting.

IMAGE COPYRIGHT
Images posted on UnmannedSpaceflight.com may be copyrighted. Do not reproduce without permission. Read here for further information on space images and copyright.

OPINIONS AND MODERATION
Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators.
SUPPORT THE FORUM
Unmannedspaceflight.com is funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member.