For the approach movie we converted the moons to grayscale because otherwise the color fringing from slight misregistration was too distracting.

I think the public image upload capability at missionjuno is now live -- https://www.missionjuno.swri.edu/junocam/processing and push the upload button in the upper right corner.

This looks really good. You might consider rotating it so north is up.

Finding better ways of enhancing the moons without bringing up the noise background is something we spent a fair bit of time on. I found that masking the planet and then linearly stretching the background worked OK, though if you make the mask too large you cut off the moons near the planet and if you make it too small you end up with a ring of stray light around the planet.

BTW, the planet gets very small but marble movie becomes interesting later on as the spacecraft approaches the equatorial plane and you can see the moons' motion become more and more linear.

Yes, that seemed to creep in during the manual processing phase and would have to be fixed before someone made a movie just from those frames.

Note that unlike the approach movie images, which had to be full-spin 82-frame images, now that we're in orbit we are able to use "nadir mode" which times the image acquisition based on s/c attitude knowledge of when Jupiter is in the FOV. This reduces the data volume a lot, but has the unhappy side effect of splitting the planet across two green framelets for most of the RGB images, which makes processing a bit harder depending on how one does it.

Note that two flavors of our processed approach movie images are at https://www.missionjuno.swri.edu/junocam/processing -- I think what they're calling "level 1" is color-registered but unstretched, and what they're calling "level 2" is rotated, stretched and hand-processed to remove noise and other artifacts from the automatic processing.

This may be true in some idealized mathematical sense, but I think for cases of real measurements with error and uncertainty, some configurations are much better determined than others.

In any event, what counts in the end is how well the images can be processed, and I look forward to seeing how your processing and that of other amateurs compares with ours.

Because of the flyby geometry and the sun-pointing spacecraft, this was simply never an option.

To be honest, I'm not really sure what you're trying to do here. IMHO, the small-disc Jupiter images are not great for assessing fine-scale distortions because they don't cover a large area of the field and there's not a straightforward error metric that you can minimize, like residuals in star images would have. Unfortunately we haven't taken RGB star images because of TDI limitations, but maybe we need to look into what we could do along those lines.

Be warned that spin axis knowledge may need to be refined post JOI and PRM burns because of s/c balance changes. There's also some evidence of nutation effects that I have yet to track down.

Mods: I think that this whole discussion should be moved to the "Juno PDS data" subforum, and that subforum be renamed to better reflect a detailed technical discussion of Juno instrument specifics.

These only sense orientation, not position.

Deep Space 1 used visible asteroid imaging to autonomously determine its position.

Voyager used an articulated scan platform with fairly coarse position feedback. It also used coarse sun and star sensors (the star sensors locked on to one bright star, no scanning of any kind) for attitude information, and for Voyager 1, one of the star sensors failed just after the Jupiter encounter -- https://oce.jpl.nasa.gov/mib/VOY-1.pdf

Remember that Voyager was designed in the early 70s before solid-state imaging even existed. Modern spacecraft use much better star cameras for attitude information, and usually don't have scan platforms (for better or worse) and even then the pointing is typically not accurate enough to perfectly line up colors.

That said, I have no idea how accurate any particular Voyager C kernel might be. Those derived from fitting of the limb in the image (so-called "C smithing") could be very accurate.

One minor nit: two of the last three images (1586 and 1588) were taken with TDI 1.

It may be worth pointing out that south is up in all of these. Our final processed images are rotated 180 degrees.

I packaged up our processed images last week, but getting those files up on missionjuno is still in work. Maybe next week they will show up.

Depends on your definitions of "plans" and "near".

There are always plans. See, for example, "Uranus and Neptune Orbiter and Probe Concept Studies", http://sites.nationalacademies.org/cs/grou.../ssb_059323.pdf

In the last decadal survey (for missions through 2022), a Uranus orbiter and probe mission was ranked third after a Mars sample return cacher and a Europa orbiter/multiple flyby mission. Given budget realities, I think it's very unlikely that a Uranus mission will happen in that time period, and after that, who knows?

Despite the color misalignment, considering the method it's quite impressive and indicative of the amount of work you've done that this product is as well-aligned as it is. I made the decision with my movie processing to not try to model the camera at all, which actually works better in most cases while completely choking on images where the planet landed on framelet boundaries -- those had to be fixed by hand.

Are you using the C kernel data or coming up with some independent estimate of s/c orientation based only on camera images?

BTW, there is a large high-latitude shadow of Ganymede in frame 1196-1199 or so.

There is a certain amount of overhead in putting the images on the missionjuno website and the advance thinking was more about the smaller number of orbital images than these big movie datasets.

That said, I expect some processed version of the approach images to show up there in the next week or so.

We have no control over the lighting, but every image Junocam takes can potentially contain the fore and aft limb.

If you do the latter then it's a little more obvious which band is which, and people can get into Photoshop and hand-register the images, though I sure hope no one is obsessive enough to do all 1400 images by hand that way!

We considered putting out only the framelets containing the planet and a few surrounding ones, but raw is raw. My processing generates color-registered 800x400 images and throws all intermediate products away. We thought the 800x400s were too processed, though most people would probably be better served by something like that.

See http://www.theatlantic.com/science/archive...r-space/491963/ for an interesting take on the raw data release.

Be warned that these all-spin images are large (1648 wide by 128*3*82 high) and mostly black, though the PNG format compresses them reasonably well.

Here's a graphic that describes the processing flow at a very basic level. Note that for the movie we just aligned the images in the three colors, there was no additional geometric processing.

Enjoy!

After the descent stage flies away? You'd need a rather long cable.

No.

They don't let me go into details but let's say that I am not having to do any software work this week on MSL.

It's about 15 km/pixel over the poles and about 4 km/pixel at closest approach.

The IFOV (per-pixel field of view) is 673 microradians, so the resolution at distance d is 673e-6*d.

http://link.springer.com/article/10.1007/s11214-014-0079-x

I believe that C kernel production is on a weekly cadence; the most recent, http://naif.jpl.nasa.gov/pub/naif/JUNO/ker...9_160625_v01.bc was posted on 29 June and I expect the next set to come out tomorrow. This would have been too late for our processing, so it was the right call. Of course it's not clear that using C kernel information would have been better. Instead we just used OpenCV "blob detection".

Thank you. There hasn't been much discussion of how the movie was made. We took highly compressed RGB images once every 15 minutes for 17 days (every 30 minutes on day 1), from 12 June to 29 June, with a few multihour gaps. The decompressed and dark-subtracted images were processed through a pipeline I wrote in Python using the OpenCV toolkit, which finds the planet in each color band, subpixel registers the colors to each other, rotates the image to north up, attempts to mask out the planet and then stretches the background harder so that the moons are visible, and then composites everything together. (No spacecraft attitude telemetry was used because we weren't sure when the C kernels would be available.) Images where the planet was split across filter boundaries had to be fixed manually using a GUI I hacked together. Those frames were then handed off to my colleague Mike Ravine, who laboriously fixed all of the remaining stray light, noise pixels, color misregistration, etc by hand. Those were handed off to JPL for production.

Sorry about the lack of release of the raw data. That decision was made above the pay grade of anybody at MSSS.

By the way, there should be a new documentary about Juno on the Science Channel tomorrow at 9 PM Eastern/8 PM Central (6 and 9 PM Pacific). If it didn't end up on the cutting room floor there should be some MSSS material in it.

https://youtu.be/XpsQimYhNkA is a link to the full Juno approach movie as shown at the press conference.

I hope that a more stripped-down version if not the original frames will be available soon.

"raw binary data streams"? They're just normal 2D images, in row-major order, with 8 or 16-bit pixels. You could load them raw into Photoshop if you read the image dimensions out of the label manually.

Unpacking the framelets might be a bit of a challenge, but we do that for you with the image releases that have actual content, like EFB.

Most simple manipulations are a few lines of code in any modern processing environment.