Maybe software could use sparsely timed images (like Spirit's DD sequences) to detect a DD with software and then trigger high frame rate video (without motion detection). But I don't know if there's much we'd learn from DD video.

It may depend on what we see - if there are lots of DDs, we'll catch some by accident.

Certainly it's conceivable that we could run a Navcam sequence looking for dust devils, find one, slew the Mastcam to it and start a video acquisition. That capability doesn't exist right now, though, and I don't know if the science value would be worth the effort.

Pathfinder, Spirit, Opportunity, and Phoenix returned their first images of dust devils serendipitously. All but Phoenix had dust devil campaigns prior to the first detection of a dust devil in an image, also. I would expect "exploratory" observations to have a different priority and implementation from "monitoring" observations. I think that with previous missions, the frequency of intentionally looking for dust devils vaguely correlates with the amount orbital evidence for dust devils in the area. M34 has some neat advantages over Navcam if you have reason to believe its FOV is sufficient--it would have been great up in the Columbia Hills--but Navcam's FOV is better for exploratory surveys, as with MER. Of course, exploration frequently follows many paths.

I must admit there's something I don't understand.
I understood that, once the covers of the Hazcam have been removed, they were to kind of hanging somewhere (I mean not on the ground).
Looking at the bellypan or whatever you call it, I can't see those covers.
Any thoughts?

If you look closely at the bellypan, underneath and offset from each of the hazcam lenses there is a spring. We know that the hazcam lens covers were designed for a one-time deployment; the springs were supposed to move them completely out of the way of the lenses, for good. My guess is that the lens covers are out of sight on the bottom of the lens housing, one each attached to each spring visible in the MAHLI images.

-the other Doug

This video explains it all : http://mars.jpl.nasa.gov/msl/multimedia/vi.../index.cfm?v=53

There were several posts about this topic on the landing or pre-landing thread.
You can see the springs (cyan arrows) and the covers (red arrows) on this crop image.

Rotating the video image shows how the cover may be hidden behind the spring.

Thank you ALL!
Believe me, I read ALL posts but can't remember understanding where they'll end up. Yes, spings are very evident to me for sure and I though covers have to be somewhere but I couldn't see them. Video also helps.

I've noticed that they're really compressing the living daylights out of MSL images before putting them on the web - much more so than the MER images are compressed. Or are we talking about a different kind of artifacting.

I think the main problem behind the most artifacts is JPEG compression. I think they should try PNG or a less agressive compression scheme.

The problem with the sun image is that the public images are lossless -> jpeg rather than lossless -> debayer -> jpeg or just lossless. That's the same problem that gives the green splotches on landscape shots.

I haven't noticed that - could you give an example of that? Or did you mean the bayering problem?

I think they're just using a fixed quality (75, maybe?). Of course it doesn't help that there is sometimes a decompress/recompress and that they JPEG-compress Bayer-pattern data. The final compression ratio seems to be around 8:1 to 9:1. Are the MER images really a lot lower compression ratio?

For the 100mm sun image, since the filter cuts out all of the pixels besides blue anyway, you'd be better off just tossing the other Bayer positions and then upsampling as desired. But it's still going to be a round slightly-fuzzy circle with a bite out of one side.

I though the cameras basically return JPEG compliant data so that there shouldn't be a need to decompress/recompress the stream again. Are they really doing that for color images?

http://pds.nasa.gov/tools/policy/ExplicitP...tsStatement.pdf

Now, you could claim that this doesn't have to apply to public release images and I wouldn't argue with you, but it would require delivery in two forms unless there was a decompress/recompress cycle.