Perijove 1 (PJ1), August 27, 2016 Options

[Gerald]

A 4-fold reduced level-2 version of the PJ1 JunoCam color images:


I'm going to prepare the 30 pixels/degree version for upload. I'd think, this will take another hour or two.

[Gerald]

Level 2, 30 pixel / degree PJ1 images are uploaded.

Image #06104 is of sufficiently small file size, that I can post it directly:


It should show Jupiter, Io, Europa, and Ganymede.
Io and Europa are small dots in this image.

[Matt Brealey]

Gerald : Thanks! You’re absolutely right that (at least so far) everything I’ve put together has been through working purely in 2D. I did initially grab some data from Horizons to actually model Jupiter/PJ1 in 3D, however I couldn’t find a good source for JUNOs rotation at any point along it’s path.

Interestingly, re-projection of image data onto a base geometry is actually a very common technique in VFX, and if I can find a suitable way of modelling JUNOs actual position/rotation I’m very interested in exploring it further as we get access to the next set of data!

I also wanted to quickly say that your images are consistently phenomenal, and I must admit to being slightly in awe of the technical knowledge that goes into them! That last image of Jupiter is, of course, no exception. Amazing work!

tanjent/mcaplinger/Gerald : The Rossby waves did confuse me slightly as well when I put the images together! Thanks for the explanation - I have so much interesting reading to do

Cheers!

Matt

[Gerald]

Matt, your de-lamberted versions remind me, that I'm still at the very beginning of JunoCam data reduction.
You really found a quick way to get managed raw JunoCam data. In 2013 it took me more than a week to get acceptable results.

Regarding 3d:
You may go the tedious photogrammetric way, or use the available 3d data.
There is still some time until Juno's science orbits to learn more about SPICE.
Login via ftp to anonymous@naif.jpl.nasa.gov and change directory to /pub/naif/JUNO/kernels to get access to the 3d data. Usually you need only the newest files in each of the directories. However Juno's precise camera distortions are a matter of ongoing investigation.

[mcaplinger]

everything I’ve put together has been through working purely in 2D.

Frankly the results are cosmetically better than what we are getting with the full 3D solution, so why change anything if it's not broken? As the spacecraft gets closer to the planet and its position is changing more across the image acquisition, the 2D solution may break down. And with 2D you probably don't have a good mapping to absolute lat/lon. But for visual examination your products are IMHO the best so far! Of course a lot of that is the sharpening and photometric removal; I'm very interested to get more details about your workflow for that.

[Matt Brealey]

Gerald : Wow, thank you so much for informing me about SPICE! I had no idea that even existed. It looks like an incredibly deep system but I’ll start chipping away at it and seeing if I can figure out how to get useful 3D data out for this purpose. The program I’m using for the 2D work is also python enabled and has a full 3D environment, so I’m curious how far I can go to integrate the SPICE python wrapper into the process! I feel like optimism is key, here

mcaplinger : That’s very kind of you to say, thank you. I definitely agree that the 2D solution will likely become more difficult on the next closer orbit (and the lat/lon disparities are likely already quite large). I do wonder how much a hybrid method would improve the process - first reprojecting the JunoCam frames onto a geometric Jupiter stand-in in 3D (with data from SPICE), and then using that as a guide to improve the warping I am currently doing in 2D (hopefully minimising the lat/long issue in the process). I'll actually be starting my write-up of the first method this afternoon, and will post a link to it here once I've finished.

Cheers and thanks again for the encouragement - it's very much appreciated!

[Gerald]

I tried to create a stereo image from JunoCam images #6180 and #6182, since they show the same high cloud towers. I found out, that it's very close to the limit of (my) perception. I've been wondering about a bright cloud embedded between larger cloud structures (close to the bottom, a little right of the center) ; the bright cloud ends abruptly, marked in both images by a few dark pixels.
At the end my stereo attempts ended somewhat ambiguously, but while trying to squeeze out as much structure as possible to help the eyes with identifing parallaxes, the images improved esthetically. So I decided to create a finalized version along these esthetic criteria:

(I've submitted the image to the missionjun site.)

[fredk]

Here's a quick and dirty registration of those images (some scaling, rotation, and translation):

I see no sign of relief at all, apart from the overall tilt ("DC component").

It would be a trivial calculation to estimate the pixel offset due to expected cloud height differences (<~100 km??), given the known (or calculable) baseline between those frames. At these kinds of distances I'd guess the expected offsets are subpixel and that we wouldn't expect to see any stereo relief.

Also, if you see an offset in a cloud feature between two frames, it might also be due to actual cloud movement (relative to surrounding cloud features) during the interval between the frames. Ie there's something of a degeneracy between stereo relief and relative cloud movement.

[Brian Burns]

Matt,

You might have come across SpiceyPy - I've had good luck with using it - there's a small example here - http://www.unmannedspaceflight.com/index.php?showtopic=8219. And I must say the documentation for SPICE is excellent...

There's another system called ISIS which lets you attach SPICE information to a labelled image and automatically project it to a map, then project from a map to camera space. It also apparently handles image registration and alignment to correct for inaccurate SPICE pointing information (which is an issue with Voyager images, not sure about Juno). Your system might handle similar situations, or you might be able to get it to work with less trouble than learning ISIS - I'm still banging my head on it!

Good luck!

https://github.com/AndrewAnnex/SpiceyPy
https://isis.astrogeology.usgs.gov/

[Roman Tkachenko]

Here is my version of image #06186
There is only manual alignment and stitching, no automation was used.
And of course this processing is more artistic than scientific.

[Gerald]

...
It would be a trivial calculation to estimate the pixel offset due to expected cloud height differences (<~100 km??), given the known (or calculable) baseline between those frames. At these kinds of distances I'd guess the expected offsets are subpixel and that we wouldn't expect to see any stereo relief.

Also, if you see an offset in a cloud feature between two frames, it might also be due to actual cloud movement (relative to surrounding cloud features) during the interval between the frames. Ie there's something of a degeneracy between stereo relief and relative cloud movement.

Subspacecraft latitude changes between -58.2 and -64.2 degrees, ignoring longitude, it's 6 degrees.
Altitude varies between about 39,000 km and 31,600 km, say a mean of about 35,000 km.
100 km / 35,000 km = 2.8e-3. Multiply this by 6°, and you get 0.017° as a parallax order of magnitude.
The fov is about 60° for 1600 pixels, hence about 0.0375° per pixel.
Divide the two angles, and you get a 0.45 pixels parallax order of magnitude estimate.
Consider, that for a group of pixels, you can easily perceive displacements of 0.25 pixels, in some cases down to 0.01 pixels.
Well, conditions aren't perfect due to the fuzzyness of the clouds and the lossy compression.
We end up again in an ambiguous state at the limit of perceptivity.
To squeeze out relative displacements, you first need to stretch the images in a way, that most of the global distortion is removed. But I wasn't perfect in this aspect in my draft experimenting. Posting it wouldn't resolve the question either. Might be, better-quality processing would.

The images have been taken about 4.5 to 5 minutes apart, say 300 seconds.
Hence we need a relative cloud velocity of about (35,000 km x tan 0.017°) / 300s = 10.4 km / 300s = 35 m/s perpendicular to the camera to compete with the parallax.
Feasible, too.

[fredk]

Thanks for the numbers, Gerald. I should stress that I pulled the figure of 100 km straight out of a hat - I know nothing about the Jovian atmosphere. (100 km is large for the earth.) Also important is the steepness of features: if the cloudtops ramp up to a 100 km height difference in 10 000 km horizontally then that would be hard to see. To see subpixel (or even superpixel) offsets you'd need good contrast and good S/N.

Perhaps experts can chime in on expected height differences and windspeed differences.

[Gerald]

Directly at the abrupt end of the bright embedded cloud, I think, we have such a steep ramp with a hard contrast. This has been the location, where I was most inclined to see a subtle parallax. But well, maybe this will stay an open issue until we'll hopefully get closer-up images later this year.

[tanjent]

And of course this processing is more artistic than scientific.

To me at least, some of the features as you have developed them call to mind van Gogh's "Starry Night".
Thanks for paying attention to that aspect. The first Pioneer and Voyager images startled us with the beauty of Jupiter's banded regions, but now something equally striking.

[Roman Tkachenko]

To me at least, some of the features as you have developed them call to mind van Gogh's "Starry Night".

Thank you. I noticed that too.