Well, maybe. There are clearly a whole lot of stray light artifacts in later images as the sunlit limb comes into the FOV (see image 10, for example) -- you can see hints of this in your version of image 6.

I wasn't expecting so many radiation artifacts in these images, but honestly we only took them because we had nothing else to take with the planet out of the FOV.

Prove it, by plotting the expected geometric limb of the planet on this image. I think this is much more likely to be a stray light artifact.

I took a casual look when they came down. There are a large number of particle hits in these images; I see a few things that could be stars but they don't jump out as such and that wasn't what we were trying to accomplish (of course, I didn't see any lightning either but it's a long shot given the short exposure times.) There's more work to do with these images if anyone is interested.

Yes, they were saved, and no, the test patterns don't cover much of the field of view.

https://mars.nasa.gov/msl/multimedia/raw/?r...1_DXXX&s=45 was taken at 17:27 LMST, which I think was somewhat before sunset.

See MSL sol 1637 (I think) and sol 1817.

I'm pretty sure it's never dark enough at the zenith to see stars from elevations anywhere near the datum. Top of Olympus Mons, I don't know.

Without doing the math in detail, I think the following is true: if you could see Jupiter in the daytime, it would be like seeing Venus in the daytime on Earth -- possible if you know just where to look, but not anything like obvious.

I presume the OP meant in the daytime.

With all due respect to pre-spaceflight artist's conceptions, I don't think you can see stars in the daytime on Mars any more easily than you can on Earth.

Another bit of trivia: this is the only part of the DEA software that was written after launch, and has only been used for the MARDI DEA. The other cameras are still running the same version of the software they were loaded with back in 2011.

Certainly (see https://en.wikipedia.org/wiki/Longitude_(book) ) but as I noted this is not to any accuracy and AFAIK has never been used for Mars rover positioning as there are better ways to do it.

I'm not sure you can position the sun very accurately with imaging on Titan, but my point is, you don't have to.

That gives you rover orientation for antenna pointing, but AFAIK, not absolute location to any kind of accuracy.

For Titan, I would expect Earth-based radiometric positioning to be accurate to at least 100s of meters, easily good enough for vehicle navigation.

From the article:


And it's unlikely that the vehicle will have enough range to fly from equator to pole.

I share everyone's excitement, but we are unlikely to get a lot more public information about either of these missions before the downselect, and the decision isn't made based on popularity. You can go back historically and look at which missions were competing and which were selected, but even if there are clear patterns there, that's not a great indication of future decisions.

The standard deviation of our model validation efforts to date (based on comparing the observed vs predicted position of the galilean satellites on orbit 1) is about 1 pixel in X and about 2.8 pixels in Y, but that probably doesn't get more than halfway to the edge of the field. The presumption is that the larger Y error is due to timing slop.

Try as we might, I'm not expecting that we will ever come up with a subpixel-accurate model that works across the whole field without some kind of ad hoc adjustment (at a minimum, a per-image timing tweak). I'd love to be proven wrong.

No way. The minimum interframe time is about 200 msec, 10x longer than what you suggest. The camera has to flush the CCD and then read out the subframe between each frame.

You can try that if you want to, but I'm not sure if those boresights have been corrected for distortion -- we use the JUNO_JUNOCAM frame in our recommended processing.

This is the best image of the cal target I've seen, and you can see the "MARS 2010" that we didn't update after the launch slip.

If you want to post that or start a new thread it seems completely reasonable. It could go in http://www.unmannedspaceflight.com/index.php?showtopic=8143 or http://www.unmannedspaceflight.com/index.php?showtopic=8353 -- the latter is misplaced IMHO because "Image Processing Techniques" is intended to be non-mission-specific.

As I've said previously, the flat field is more complex than just putting up an image. Our ground flat fields consist of readouts of the entire active part of the sensor, only 128-line pieces of which per filter are sent down in flight. And then with TDI active the image moves across the sensor and blurs out the blemishes. All of this could be documented in a self-contained fashion, but I just haven't had the time. I've attached a normalized 8-bit version of the flat (IIRC this appears as a figure in the Junocam paper) and a binary blemish map of the RGB part of the sensor that gets read out (the latter is what we are currently using in our processing flow to repair blemishes, but it's fairly quick-and-dirty.)

There is a beta version of ISIS3 that supports Junocam. I was told not to distribute it "outside the team" but since everyone here is on the Junocam team I'm not sure what that means. If you're interested PM me with details about which platform you want it for -- it's available for the 64-bit version of Mac OSX 10.11 and various 64-bit flavors of Linux. It's worth noting that ISIS3 has a very very steep learning curve so this is not something you should ask for casually -- you might start by downloading the production version of ISIS3 to see if you can figure out how to use it on a simpler case.

As for a unified thread about Junocam processing -- I'm not sure there's a unified thread about anything on UMSF, but it's a good idea in theory. The thread over in http://www.unmannedspaceflight.com/index.php?showtopic=8353 is an example, perhaps overly specific to the standard SPICE formalism. Some amateurs have documented their workflows in fair detail, some have not (which is fine) -- I am always curious to see how people are doing what they are doing.

With pxform and all the right kernels loaded, you should be able to go directly from the IAU_JUPITER frame to the JUNO_JUNOCAM frame without that other stuff. Not saying what you were doing was wrong, but it's a potential source of confusion.

I think 0.2 degrees is about 1 second of timing error, which is way bigger than what I would expect.

I tried to document what I think is the correct way to do this in the Python snippets in https://naif.jpl.nasa.gov/pub/naif/JUNO/ker..._junocam_v02.ti -- I presume you saw those.

Mostly off-topic but I'll just leave this here: https://eos.org/agu-news/malin-receives-2017-whipple-award

Yet somehow this happens for MAHLI.

Isn't this image data draped over the DTM? If it wasn't, there wouldn't be any albedo features. Since it is, the BRDF is baked into the image at least for the original imaging geometry.

The PJ9 images are on missionjuno (although the front page doesn't say this yet.)

You mean "you are". My name's not on the abstract.

If you don't want to release something, then don't stand up at a public conference and present it.

There's a DPS abstract online for this, although it has some coy language: "These observations reveal a turbulent environment with an unexpected structure of cyclonic polar vortices."