Awesome stuff, image-wise this is one of the most spectacular threads I remember seeing at UMSF. A suggestion however:

Many of these images are hosted at external sites like flickr.com or imgur.com which might cause problems in the future. If these external sites change the image URLs the images in the UMSF threads probably disappear - in particular, this happens if some of these external sites simply disappear. Here is an example of a thread where something like this happened - lots of bad links to images:

http://www.unmannedspaceflight.com/index.php?showtopic=2222

It would be a pity if this happened to the Juno threads since many of the images here are highly spectacular. Therefore it is a good idea to upload at least some of these images here at UMSF - this makes them 'permanent' and not dependent on external sites. Also the image thumbnails become smaller in this case which is a plus. It's rather easy to overlook small posts like Gerald's two recent posts when you quickly scroll through a thread that contains lots of big images.

Good idea. However, the 1MB limit on file size may not permit us to enjoy the full glory of these images. Is there any possibility of increasing this limit?

I would encourage all of you who are doing this great work to offer the full size images to the Planetary Society's image library. This forum could keep a half-scale or compressed version.

Phil

At least some of the Jupiter images are already in the TPS image library.
Here search results for Seán and me. Someone at TPS seems to select some images, occasionally. Initially Emily has been working hard on this. I know, that she has several jobs now, and I'm not quite up to data, whether she currently has time to maintain the database herself.
I'm also using to upload some selected images to the missionjuno site, where I hope, that the images will persist for a few years, at least. And some images have been selected as APODs or for NASA's PIA.
I'm hosting most of my image products on the junocam.pictures webspace, which my provider will hopefully be able to keep online over the next several years. I've a local copy of this site, in case the site will be shut down for some reason.
So, I hope, that we have sufficient redundancy, that not everything will go lost. I'm open for additional archiving concepts. Technically, the upload limit in UMSF can be increased. But we may get 10s or even 100s of gigabytes of JunoCam image products over time. I'm currently prepared for up to 500 GB on my webspace, about 10 GB per perijove plus some margin. But I guess, this load would be above reasonable restrictions for UMSF. And only a small subset of my image products looks "pretty" or is intended to look pretty, or is even valid for public attention.

Here are my versions of the PJ-6 111 image ("POI: Maximus Spatium"; JNCE_2017139_06C00111_V01). Juno's altitude was 12579 km when the raw framelets were obtained. As usual I made these images by reprojecting the raw framelets to simple cylindrical projection and then rendering the resulting map from Juno's vantage point.

First approximately true color/contrast versions. Small scale details have been sharpened slightly:




And versions with enhanced contrast and color and where small scale details have been further sharpened. The effects of global illumination have been removed.




And now something completely different. Asking for additional data in the metadata files might be asking too much but I can't resist: It would be very nice if the compression ratio was included. I have noticed that the compression type is included and it usually is integer cosine transform. I think I may have detected a few very subtle compression artifacts in a few images - I'm not sure though.

I thought, I should post this rendition of PJ06#92 with the large tangential shadow:

I've used the "pinkish" color weights with 0.88 / 1.0 for red/green.
I've rendered the image in one step directly from the raw with 60 pixels/deg, including reprojection, hence supersampled by a factor of about 2, all intermediate calculations in double precision floating point in order to avoid numerical truncation artifacts, and without intermediate image representations to minimize loss of data. The processing uses SPICE trajectory data in several reference frames, and assumes a Jupiter MacLaurin spheroid rotating with system-III angular velocity. Reprojection is to spherical coordinates at image stop time, with Juno's spin axis as approximate axis of the spherical coordinate sytem.
This version tries to adjust illumination including the terminator, despite the poor S/N for this almost dark zone, in order to see the shadow of the moon as far as it can reasonably be persued.
I didn't apply any sharpening nor other post-processing, except rotating by 180 degrees to have north up.
Camera artifacts aren't patched in this version.

The image is an excerpt of the products of one of 4 jobs I'm currently running in parallel on PJ06 data.
I'm expecting to be able to upload the results of two of the jobs tomorrow, i.e. 2-fold supersampled versions of the PJ06-images (still with camera artifacts), terminator slightly darkened, one version with 0.82/1.0, the other one with 0.88/1.0 for red/green weights. The images will cover several Approach and Departure images as well as RGB close-ups, provided my computer is willing to complete the according jobs.

I agree with Björn, that there are some subtle processing artifacts in #111. However, most PJ06 images appear to be less compressed than we've seen sometimes before.

More from Gerald's PJ06 work...

PJ06_110


PJ06_111

This is a crop of an enhanced version of PJ06#133 with the best lightning candidate I've seen thus far in JunoCam images:

Thank you Gerald and Sean and others who process and present these amazing images. The volume of images limits what can be worked up even on the 54 day orbits. Think how much would have been lost if we were getting this volume very 14 days.

Here the 2-fold supersampled reprojections I announced yesterday:
- greenish version,
- pinkish version.

The full images the overview sites link to are 5-times larger, and especially the close-ups may challenge some browsers or computers. Reducing the zoom-level in the settings of your browser may overcome these limitations in some cases. Might be, downloading the images and viewing them with a different software works where the browser fails.

And yes, the time between perijoves allows only for a portion of the conceivable processing. It allows for learning from the previous perijoves, and for refining observation strategy and processing techniques. 14- or even 11-day orbits would have been very tough.
Rendering the above images has already been challenging, but creating good seamless map products is another factor of more than ten. One of my attempts today ended up with an almost frozen user interface, since the available RAM exceeded, and swapping slowed down any interaction to almost zero. I managed to move the almost frozen mouse cursor onto the close-button of the process, pressed left mouse button down, and half an hour later the computer was operational again without risking damaged hard drives due to hard powering off.

Wow Gerald! I wish I had more time to work on these. Thank you again for your amazing work!

Here is an 8k from your new supersampled batch...

Yes, it would have been difficult to keep pace with a 14 day orbit so in a way the 53 day orbits are a blessing for us here.

One of my main conclusions from processing the Juno images is that I need a bigger computer, even though my computing runs are fewer and much smaller than yours (four ~5 hour runs today that I do in parallel by running four instances of the software I wrote to process the framelets).

Interestingly I'm getting considerably better results for the PJ6 images by using a value of 0.374 for the interframe delay instead of the 0.373 value from the metadata files. This could also be due to something else (e.g. the spin rate) - see Mike's reply in the PJ5 thread where I also decided to increase the interframe delay by 0.001 when reprojecting the images.

I'm calibrating the ratio of Juno's rotation and interframe delay anew for each perijove, provided Approach and Departure images get available. For perijove 6, I've been lucky, that my PJ05 calibration data worked acceptably well for the first run of the close-ups. For the latest supersampled series, I adjusted Juno's rotational period to 30.27956 seconds and 80.96 interframe delays per rotation for the approach sequence (considering #57 and subsequent images), and to 30.29973 seconds and 80.80 interframe delays per Juno rotation for the departure sequence until #159.
With #161, Juno's angular velocity seems to have started to change again, on the basis of the SPICE and metadata I've used. Therefore, my supersampled series ends with #161. I'd prefered to cover 10 hours after PJ06, but the effort to adjust parameters for the last few images didn't appear justified thus far.
During the close-up sequence, I switched with #111 to the departure convention, but needed to adjust the pointing by about 3 degrees for #111. So, the change of Juno's angular velocity may have taken a few minutes.

Btw., I had the same thought about my computer. More cores and more RAM might accelerate some of the jobs.

hi everyone ! My Name is Toni ! This image is based on initial processing efforts by Gerald Eichstädt. n 00128 ! I've improved contrast, sharpness, and curves! Thanks Gerald !
 

Image Credit: NASA / JPL / MSSS / Gerald Eichstädt / Toni Uddo

hi everyone ! This image is based on initial processing efforts by Gerald Eichstädt. n 00122! I've improved contrast, sharpness, and curves! Thanks Gerald !
 

Image Credit: NASA / JPL / MSSS / Gerald Eichstädt / Toni Uddo

and a dettail Image of n 00122

Image Credit: NASA / JPL / MSSS / Gerald Eichstädt / Toni Uddo