Expect a partial set of images from PJ7 to show up on missionjuno in an hour or so (posted 07:23 PDT on 12 July.)

UPDATE: images posted as of 07:49 PDT.

For those following along, we switched to the 34m net about 10 AM PDT, and this only supports about 30 Kbps. That'll be near-continuous, but I don't think we get more 70m time until mid-day PDT tomorrow.

It's a mission goal to do this at least once. Since neither the long-term position of the GRS or the exact orbit parameters can be predicted exactly, there's no way to know when in the original mission plan it would have happened.

Pacific Daylight Time (UT-7h) I presume. You can look at https://eyes.nasa.gov/dsn/dsn.html to see when Juno is being tracked; we have to be on a 70m antenna to get a decent downlink rate.

If an image contains the entire target planet, then none of the four corners intersect the planet, and if the planet were off-center, the boresight might not intersect the planet either, but the footprint would still be the entire visible part of the planet.

Since the companding maps all input values from 1392 to 1407 to 209 (for example) there's no way to uniquely recover the input, obviously. This is more obvious for Junocam where the companding is done in a piecewise linear fashion and there is a slope change at 209-210 (in contrast to MSL where a smoother full table is used). At various times people have talked about intentionally adding gaussian noise back into the decompanded values, but I've never tried this. Depending on where in the processing flow you do the decompanding relative to other operations (photometric removal, for example) and what precision you are doing this to, you may or may not be quantizing the values further.

That's Mars Climate Orbiter. The Mars Observer problem was a lot more subtle (as was the Galileo problem.)

Wow. Basically there were several issues, but there was one parameter that was supposed to be 15 msec and was set to some unstated larger value and nobody caught it.

That's gotta hurt.

The image above is from PJ6-0113 from an altitude of 5110 km. The clouds are typically about 5-6 pixels in diameter in raw images, which at nadir would be 5.5*673e-6*5110 = 19 km. This is off-nadir somewhat and I'm too lazy to do the geometric processing, but that's a rough order of magnitude -- 20-40 km.

There's a way of indicating the source image when you submit, but I've never submitted anything so I don't know how it works.

You could always put a label on the image if there's a good place to do so, but it does interfere with the aesthetics.

As an aside, also true for Mastcam/MAHLI/MARDI, which inherit their autoexposure algorithms from Navcam. I've been surprised at how few manual exposures there have been.

Great question. It's fairly easy to figure out from the metadata, but I'm not sure which image this is from or whether any scaling has been done. If you have the altitude from the metadata, then the pixel scale of Junocam at nadir is just 673e-6*altitude in whatever units the altitude is. Of course, farther away from nadir the scale goes down because the range is larger.

I'm amazed at these products. To be honest, we didn't know that half this stuff was in the images ourselves. I hear there was a lengthy discussion about the small clouds at the science team meeting yesterday.

If I could make one suggestion, it would be to include the image identifier somewhere for reference along with every processed image. I prefer the shorthand notation (e.g., pj6-137) instead of the long-winded image ID ("JNCE_2017139_06C00137_V01") that appears in the metadata, but the latter is the official name.

Everyone who's processed images from PJ6 (Sean and Justin in particular), if you could upload your images or your favorite subset to missionjuno, Candy Hansen is currently at a Juno science team meeting and would like to highlight your work. Gerald's are obviously there already.

Beautiful work. Maybe someone could take a run at correcting the color manually. I can't really publicize this as is because I'll have to field too many questions about why it's so green.

AFAIK any saturation is only happening near the limb in some of the images. Even the nadir portions of these images are greenish in many cases.

There is probably a greenish/yellowish cast to images that have no color correction applied. We've reported the band correction factors in the PDS products but I've never actually validated those so if there's still some residual artifact I wouldn't be surprised. As I say, we're using a simple auto white balance which seems to work all right for Jupiter.

This is really very promising. A couple of hopefully constructive criticisms:

1 ) you might consider cross-fading between images instead of cutting. There's at least one place where the cutting leaves you with a disorienting black image, I assume because the image coverage hasn't caught up to the spacecraft position.

2) your processing has become quite excellent except for the color. I'm not sure what's going on with the color but I don't think Jupiter is ever that green. Our missionjuno processing just does an auto white-balance after delambertianing and often leaves blue artifacts near the limb and terminator, but not the overall strong blue-green cast.

Part of the PJ6 dataset has been posted to missionjuno. There were some GDS/DSN issues that are holding up the rest of it, which should be posted on Monday.

Umm, you were responding to a post nearly a year old. The recovery attempt back in 2016 didn't succeed and the spacecraft is still out of contact. https://stereo-ssc.nascom.nasa.gov/behind_status.shtml

I'm pretty sure Surveyor used an early version of the Star-37 -- http://www.astronautix.com/s/star37.html -- so 0.66 meters in diameter.

The original idea was that all images would be no larger than 1200x1200 since the zoom couldn't fill more than that area. When we went with the fixed-focal-length optics the constraint became the size of the filter. If it had been me I still would have stuck with 1200x1200 but people insisted on getting a little more coverage per frame at the cost of more vignetting in the corners, memory fragmentation, etc.

You can perform some amusing numerology by looking at sequences and seeing which ones are 1200x1200 and which ones are larger; it provides clues about who wrote the sequences and why, and how recently I had pleaded with people to stick with the smaller size

There's this thing called the weekend. If the Friday command sequence doesn't get uplinked for some reason, then the rover is in "run out" over the weekend and may not send anything, depending on the state of the downlink queues. That's the typical cause of a 2-3 day outage. You can stop worrying now.

Sure it does. It rains dust all the time. Where do you think the dust on MER's solar panels comes from?

One has to distinguish between dust, fines, sand, and other names for particulates on the basis of grain size. The stuff on the MSL deck mostly looks like sand or maybe soil to me.

There's a lot of stuff on aeolian transport of materials on Mars in the literature going back to Viking or even before.

The metadata value is 1 millisecond too small (there was an off-by-one misunderstanding about how the hardware interpreted the commanded interframe value.) Otherwise it's under the control of a fairly stable crystal oscillator but there could be some drift on order of 10-20 PPM over temperature.

The spacecraft spin rate is usually not precisely 2.000 RPM so that's probably a bigger unknown.

Altitude from the metadata is 12744 km, so resolution is 673e-6*12744 = 8.6 km/pix at nadir.