I see "encoding_compression_ratio", is that what you're talking about?

It's more difficult than you would think to add because we can't make any changes without going through another lengthy review/approval cycle. And frankly, while I admit it was an oversight, I am not seeing a really compelling need to know it. We could perhaps consider having some kind of ancillary table or text file and I'd be happy to informally distribute that.

Not sure what you mean by this.

Did you actually read the caption?

"The dark vertical streaks at the top of the image are caused by short exposure times (less than three milliseconds). Short exposure times are required for imaging an object as bright as Earth, but are not anticipated for an object as dark as the asteroid Bennu, which the camera was designed to image."

That said, I'm not sure why short exposure times would cause streaking like that -- maybe blooming from the horizontal register?

Yes, that's an example of the effect I described.

If we ever changed any of the piecewise linear companding parameters (which we don't plan to do) there is no place to record them in the metadata. One issue is that the PDS doesn't easily provide a way to define new keywords and has a pretty sparse set of standard keywords (for example, we had to lobby to get a keyword to describe the amount of TDI -- even though TDI has been used on earlier instruments, there is no standard keyword for it.)

Not publicly, no, not at this time. Some missions archive their ground data and some don't, and of the ones that do, some of them spend a lot of effort to make that intelligible and some don't. Most of our ground images were taken with ground support equipment that read out a large area of the CCD including the "junk" between band edges, and so it doesn't fit perfectly into the definition of the standard PDS product.

If I thought any of the ground images were generally useful, I'd be more interested in trying to get them into some releasable form.

A visual example of what you are reacting to would be helpful.

Without looking at these specific images, we've observed an effect where as the sensor warms up during operation, the dark level in the images interacts with the companding table in such a way as to (paradoxically) make the images less noisy, which changes the behavior of the lossy compressor. Unfortunately, the PDS archive product wasn't defined with a field to record what the actual compression factor was (that is, we don't record how big the original downlink file was), which would give some indication of what level of compression artifact to expect.


At the moment Junocam is turned off except near perijove, and the time near perijove is fully subscribed with images of the planet.

With regard to calibration, my philosophy is to try to extract all the information possible from images that we already have before taking new images. There were a few instances in cruise where the TDI was commanded assuming the spacecraft was spinning at 1 RPM and it was really spinning at 2 RPM, and these images have the kinds of streaks you're describing. We just ignored them when we were doing our calibration, but maybe they have some utility.

There are many, many images taken all the way around the orbit on orbit 1 of the moons with no TDI, and that's a good source of geometric information that we are in the early stages of looking at.

Taking long exposures without TDI is outside the parameters that the instrument was designed to work within. It might be possible to command this, but obviously you can't take contiguous frames around a spin so you'd be taking images of somewhat random star fields.

I'd have thought that the focal length would be a larger variable than k1/k2.

Gerald has said that he is getting residuals much smaller than 0.1 pixels. I haven't been able to get anything close to that good, so it would be very useful for him to document his processing in a way that could be incorporated into the I kernel.

Asked and answered: http://www.unmannedspaceflight.com/index.php?showtopic=8334

There's a stylus and instructions but no "record player".

https://voyager.jpl.nasa.gov/golden-record/...n-record-cover/

If you could document this for inclusion in the PDS kernels, that would be a very useful contribution.

BTW, note that image 114 ("Collision of colours"/"Sharp edge") was taken in lossless compression mode; several people had asked if images near PJ were being degraded by lossy compression. I'd be curious to hear if people thought it made a significant difference.

Yes. At least that's what we are suggesting you use in the camera model. No camera really has the optic axis going directly through width/2 -- if it says it does, that most likely only means that other parts of the camera model have been adjusted to compensate for that assumption (camera model parameters don't have to be physically accurate as long as the residual errors are low.)

For this most recent kernel update, we (a summer intern and I) measured thousands of cruise star image locations and then used Nelder-Mead nonlinear optimization to minimize camera model error while varying seven model parameters: image optical center (cx, cy), the first two terms in the radial distortion function (k1, k2), camera focal length (fl), and camera boresight angular misalignment in X and Y (xr, yr). The residual error is still about 1 pixel cross-spin and ~2.5 pixels down-spin (1 sigma); the latter higher because of remaining timing slop.

I don't think I follow what you're saying. Flights flying compass headings of 0 to 179 fly at odd multiples of 1000 feet MSL, headings 180 to 359 fly at even multiples. That insures minimum vertical separation. And then there are systems like TCAS to help planes avoid each other. I doubt if planning this eclipse flight was all that challenging from an ATC perspective.

FWIW, I saw a different commercial airliner fly almost across the sun west to east a minute or so before totality in Oregon but I doubt if any of the passengers could see very well on that heading. Nice for the pilots, though.

My best eclipse photo: http://lroc.sese.asu.edu/posts/980 Compare and contrast with http://www.patrawlings.com/detail.cfm?id=995

It would be fairly straightforward to colorize this with EPIC color (hint, hint) -- https://www.nasa.gov/image-feature/goddard/...-across-america

To expand on this a little, remember that Juno is solar-powered and so its solar panels must always face the sun (approximately), and Junocam is pointed 90 degrees away from the sun line. In the original mission plan, the orbit was roughly over the terminator over the entire course of the mission, so Junocam was pointed at the planet for part of every spin. Now that the mission is going to last so much longer, Jupiter moves around the sun much more, and the orbit (which is fixed in inertial space, more or less) drifts away from the terminator. If you consider the case when the orbit is 90 degrees from the terminator, Junocam never sees the planet at all for much of a perijove pass.

All of this is complicated by the slightly different orientations that are used (Earth-pointing, normal to the orbit plane, etc.) And Juno can go off-sun and run on batteries for a while, and this will likely be done for some orbits. But all of these scenarios are much more complex than what the public targeting software was designed to handle, so we are still evaluating what we can do within the constraints. Only partly in jest, I suggested at one point that we let the public figure out what might be visible from the available SPICE kernels and then let them vote on that.

There's a distant moon encounter on every orbit, for suitable definition of "distant". Or were you talking about the outer non-galilean moons?

A quick non-official survey to early 2021 shows closest approaches of 172K km to Io, 146K to Europa, 109K to Ganymede, and 678K to Callisto. None of these are close enough to be especially wonderful IMHO.

Yes, that's typical. If the kernel doesn't contain records for the geometric object you have to use the barycenter. The offset is insignificant for most purposes.

In my experience numerical values in press releases and other prose descriptions are sometimes not very trustworthy.

Your distances don't look too far off. The closest you have was 721909 km relative to the center, which is about 650000 relative to the cloud tops, so if you reduced your time spacing you may be close. It's possible that the descriptive text was approximate.

Not that I'm aware of.

However, I recently ran across http://www.mit.edu/~portillo/dsn/index.html which is based on scraping DSN Now. I have no idea if the site actually works; it just says "loading data" endlessly for me, but maybe you have to register or something, or maybe it's a browser compatibility thing.

Looks like it's an uncorrected artifact from the crud on the image sensor.

There are some charged particle hits in these images but this doesn't look like one to me.

It's always a good idea to go back to the raw data in cases like this. Things that show up in only one color are usually one of these two things.

Gravity science is a key part of the Juno mission and AFAIK not really a key part of the Cassini mission. Radiometric tracking is a complex subject and I don't claim to know that much about it. https://arxiv.org/abs/1411.1613 is a paper by Juno team members from ASI, which supplied the radio science Ka-Band Translator for Juno, so you might start there.

[added] Actually, it turns out that Cassini has an earlier version of the Ka-band translator, see http://lasp.colorado.edu/~horanyi/graduate_seminar/Radio.pdf
(which also has a description of the Cassini radio science goals.)

I'm not sure what else you're looking for here, you've captured the differences in the instrument suites and capabilities pretty accurately. The goals are very different between the two missions, and the targets are also very different. As you say, Juno has more capability for gravity science because of the Ka-band and will also do many more close passes than Cassini; Cassini was never intended to do detailed interior studies of Saturn and anything it gets will be a bonus.

Maybe I'm having some web cache problem, but the image still looks wrong upstream in post #59 (for a while the link was dead, it's now come back with the original incorrect version.)

In PJ7-0060 the east-west limb-to-limb view centered on the GRS covers about 10 degrees of longitude and the north-south extent of the GRS is about 10 degrees of latitude. See attached grid image (I apologize for this ugly figure, I don't have any good tools to make publication-quality grids.)

The scale on Jupiter is pi*2*70000/360 = 1222 km/degree roughly (using 70000 for the radius and ignoring oblateness). Longitudes have to be multiplied by cos(lat) but that's not a big effect at the latitude of the GRS (cos(22) is 0.93).

So in this image, the GRS is about 12000 km in vertical extent. That's just about the diameter of the Earth, so your revised image looks about right.

Note that the GRS has been shrinking over time, so there are all kinds of estimates for how big it is on the Web, and I wouldn't trust most of them. See http://www.lpi.usra.edu/opag/july2014/pres...-Simon_OPAG.pdf but that's from 2014.

I'm afraid I'm solidly in the "wrong" camp on this -- based on some rough sanity checks based on the size of the Spot you have the Earth 2-3 times too small. Junocam images are tricky, as the scale varies a lot over the image due to foreshortening. I wouldn't trust most people to be able to definitively figure this out; I can't do it myself without doing a little work, which I'll do later today.

Beautiful job. I think we might use this in our press release if it's OK with you. One minor quibble: these images were taken at 02:03, 02:07, 02:10, and 02:12 UT (Spacecraft Event Time) on 11 July 2017. I think there might be some time zone confusion going on.