There is an entire thread from May 2013 devoted to discussing wheel damage.
http://www.unmannedspaceflight.com/index.php?showtopic=7658

This was one of my many objections to the IMHO ill-conceived file naming convention.

Obviously the science team (of which Deimos is a member) already has the best available images.
If you're proposing a scenario where no one on the camera team can see the comet and you find it in the PDS images, that would be a triumph of amateur processing, but (with all due respect) doesn't seem especially likely.

The HiRISE image suggests the target is not very bright, but on the other hand, the exposure times for a linescan system are probably pretty short.

The camera can either take JPEG images in "immediate" mode, in which case the raw image is never stored anywhere, or in "deferred" mode, in which case the raw image is stored in camera flash and JPEGed when transmitted. In the latter case we can send it in any compression mode we want, or no compression at all, or transmit it multiple times in multiple modes.

For MAHLI, if we have the image as a JPEG, the web image is exactly the JPEG bits that we have. For Mastcam and MARDI, the web image is always a decompressed-recompressed JPEG version.
The web image is always JPEG even if we have a lossless version of the image.

I think you can rest assured that if we see the comet, we will make that fact known.

If that bill doesn't get paid, then the website will be dead (as in http 404), not just stale.

There's a rather long path between Mars and AWS.

Are you suggesting that there was methane when MEx looked, but there isn't any now? The lifetime of CH4 in the atmosphere is short, but not that short (hundreds of years.)

Occam's Razor suggests something other than transience.

Could be. I don't have a copy of Maurice et al and this is far from clearly stated (IMHO) in all the published stuff I could find.

Sorting through various references (the Chemcam fact sheet and some LPSC abstracts), the IFOV is 80 microrads and the pixel pitch is 14 microns, so the focal length is 175mm. The aperture is 100mm, so the f/number is f/1.75. The beamsplitter passes between 8% and 18% of the incoming light depending on wavelength.

[Hmm, on review the fact sheet says the "spatial resolution" is 80 urad, but that may be 2x what I would call the IFOV, in which case the focal length and f/number double.]

Viking had no ability to avoid big boulders or any other landing hazard; its terminal descent radar only measured velocity vectors. See www.cs.odu.edu/~mln/ltrs-pdfs/NASA-76-cr159388.pdf

Actually, I think the spot size is small enough that a separate wider-field (or scanned, maybe, not clear) acquisition beam has to be sent by the ground station so that the flight system can adjust its pointing dynamically -- see http://dspace.mit.edu/openaccess-dissemina....1/61673‎

You're right for this sequence (obviously you've worked with this dataset more than I have), but as you note on your web site, some of the far-encounter images were transmitted in full-res analog. See http://archive.org/stream/nasa_techdoc_197...e/n294/mode/1up

Sorry to resurrect this thread, but it was linked in Emily's blog posting on Bruce Murray and early Mariner images, see http://www.planetary.org/blogs/emily-lakda...ner-images.html

The statement about only a fraction of the pixels being transmitted is not completely accurate: see http://mars.jpl.nasa.gov/mgs/msss/camera/i..._2_00_vishniac/ and http://mars.jpl.nasa.gov/mgs/msss/camera/i...m7_imaging.html for a description of how the MM69 camera system worked. All of the pixels were transmitted, but some only in analog AC form.

As for "Murray's stubborn insistence that it would be ludicrous to send a spacecraft to Mars and not include a camera", NASA is of course just about to do that with MAVEN. The PI even speaks with pride (see http://www.aviationweek.com/Article.aspx?i...759.xml&p=2 ) about his resistance to "science creep", even though AFAIK the mission cost a fairly large fraction of the total cost of MRO -- $671M for MAVEN, $720M for MRO.

Disclaimer: being a camera designer I obviously have some bias.

In the accuracy stackup, the uncertainty in the actual RSM pointing from gear backlash, encoder/resolver precision, etc, is probably many times larger than any centroiding error from sun overexposure.

On MER they do sun-finding with Pancam, which has the same FOV as the 34mm Mastcam.

It was more a political/requirements-driven issue related to Mastcam being a non-JPL instrument. Mastcam could be used if needed but Navcam is completely sufficient.

All we had to do was get the sun in the field of view at the right time, Phobos did the rest.

Yes, almost certainly. Remember that exposing for the Moon/a moon is like exposing for any other (admittedly dark) sunlit object, so these exposure times were fairly short.

Deimos moves E-W and Phobos moves W-E because of the rotation of Mars, so I'm not sure what your retrograde reference is to.

If you didn't like the grazing observations last year, there are more chances coming up later in the month. http://meetingorganizer.copernicus.org/EPS...PSC2012-326.pdf

The full-res image you're looking at is from sequence 1424 and the better-exposed thumbnails from sequence 1423, which presumably have different exposure times.

I'm not sure myself how it's related, but I'll speculate.

The first four digits are the sol, I think that's without controversy

The two letters are the abbreviated instrument name, ditto.

The ten digits look like the sequence ID (elided from the six digits in the SIS to four digits) and the command number (three digits) in the sequence (together forming the product ID), per the SIS page 25, followed by three digits which is some kind of identifier for commands that yield more than one image (video and zstack). For normal image products these should always be 000.

The letter is the data type as defined on pages 23-24 of the SIS.

The _DXXX is as defined in the SIS page 24 and will always be _DXXX.

The digit after the data type letter is probably the version (SIS page 24), has it ever not been 1?

At this point, I would guess that we are seeing either a bug in the name generation that has been encountered for the Phobos/Deimos sequence, or a definition of the video identifier that causes it to have four digits in some cases rather than three; perhaps not a simple incrementing count. One would have to go back to previously acquired video to see.

For parsing at this point I would assume that the field between the product ID and the type could be 3 or 4 digits. As indicated previously I'm not sure how this might change in the future.

Huh. I think the extra character will appear if video is shot in "immediate JPEG" rather than "deferred JPEG" mode (perhaps the SIS explains what this means, I don't remember; in this mode there is only one thumbnail for each 16-frame "group of pictures") and I thought we had done this before (scoop video), but maybe not. There also may be future changes to the naming convention in general.

I had nothing to do with the naming convention and I also argued against incompatible changes to it, so I am not taking the blame for any inconvenience caused.

Rather than "color corrected" it would be more accurate to say "arbitrarily white-balanced."

Sorry, pet peeve of mine.

Of course there's no zoom per se. The 100mm Mastcam has about 3x higher resolution than the MER Pancam. It depends on how close one gets as to how good those images could be. For example, the MER-B images were taken at a range of about 440m -- http://marsrovers.jpl.nasa.gov/gallery/pre.../20040209a.html M100's would be 3x better.

I'm pretty sure that if there is a clear view along the route that they will try to take images. I don't know if there is any plan to tailor the route for this.

Examination of the heatshield might yield this (I say "might" because you can read the open literature (e.g., http://trs-new.jpl.nasa.gov/dspace/bitstre...2275.pdf‎ ) and see if the engineering benefit from looking at the heatshield on MER was worth the resulting contamination of the rover) but little of that applies to the backshell.

That said, I have no idea what they are planning. I agree that there is some outreach potential but IMHO there are more attractive options.

This gets you about a meter higher, but MAHLI's resolution is only about 60% that of the 34mm Mastcam.

I'm not sure what useful information could be gotten from even close examination of the backshell.

Though no fault of the NAIF/SPICE guys (we owe them an update) there seem to be some errors in that file, so I would use it with caution. For example, there's a typo in the focal length, and I think the RGB band order is backwards. I'll see if I can get the file updated in the next couple of weeks.