It's more equatorial but the same hemisphere.

Hello UMSF members,

Here are my first attempts for introducing Volcanopele work in VPA freeware.
Screen captures are :

PJ 57 et PJ 55 comparison showing resolution increase
PJ57 & Voyager-Galileo texture
PJ57 & Voyager-Galileo texture annotated
PJ57 & Voyager-Galileo texture close-up

Hope that this will be helpful to everyone
Sincerely yours
Ch. Legrand

Fortunately, the next flyby covers almost exactly the opposite side of Io. If that is successful, with comparable jupitershine imagery, we could come away with about as close as possible to global coverage with just two flybys.

I assume the two SAMPLING_FACTOR": 2 images were included just to mess with us. ;-)

Mike, I am definitely coming around to the idea that if you can get well exposed Jupiter-shine images in the green filter, being able to stack them to improve SNR and getting more of them would be fine. While RED has the best SNR, GREEN has the best balance of SNR and albedo information.

Are you sure? The outbound sub-spacecraft point was about 40N,30E for PJ57 and it's about 0N,15E for PJ58. The inbound imaging on PJ58 is pretty poor resolution while the illuminated limb is still in the Junocam FOV.

maybe they meant the area covered in Jupiter-shine? Because it would be fairly complimentary to the PJ57 coverage, getting more of the southern hemisphere coverage compared to the northern hemisphere coverage of PJ57. I'm looking forward to seeing East Kanehekili (-18/24) at visible wavelengths, as an example.

I'll defer fully on the question of which flybys offer which coverage since my visual interpretation of Jason's map was my only source, and leave that topic both to better informed people and the new threads.

ImagePJ57_23:



North is up. The brightness of the nightside has been increased to show details there.

By the way, I have noticed that the spacecraft's distance from Io as determined from the SPK kernels isn't totally accurate and this must be corrected. This is not unexpected and was also the case when processing images from the Ganymede and Europa flybys. The error is small but depending on the software used, artifacts may show up in the processed images if this is not corrected (and the START_TIME must also be corrected). The most common artifact seems to be a 'truncated' limb, I have noticed this in several processed images I have seen, in particular PJ57_22. I think ISIS3 does this (I remember also seeing this in a few Jupiter images processed using ISIS3) and my processing pipeline also does this on occasions if the geometry/time is very inaccurate. One example I saw is Kevin's otherwise excellent PJ57_22 image (IIRC he's using ISIS3) - clearly some care has to be taken when using ISIS3 to process the JunoCam images, also these artifacts aren't always obvious.

For my images, I did have to set jigsaw to correct for spacecraft position to get the limb in the right spot. Plus I had to add many tie points near the limb of 57_22 to avoid color fringing. But given that we only have the predict SPK available, yeah this makes sense.

A couple attempts at the Jupiter images, all processed with my Rust pipeline (I did my Io stuff with my ISIS+Blender method).


Jupiter, Europa, and Callisto - PJ57-28



Jupiter and Io - PJ57-60



Jupiter - PJ57-60 - Detail

So the closest images... were they lost or just degraded to they point they cannot be used? Or was imaging at closest approach not feasible?

Phil

Closest to what? Io? Io C/A was over the nightside and we didn't try to take any images.

That answers my question - imaging at closest approach was not feasible, it was over the night side.

Phil

Here's a try with the GIMP-GEGL noise filter on one of volcanopele's images, brightened to show the night side. Noise setting is 10 and brightness is +6 f/stops.



And indeed the geometry was quite interesting to deduce in terms of corrections to what was seen in Jason's preview video. Here is how I had gridded a couple of the images with assumed values of sub-point lat/lon and distance.