MARDI images and videos Options

[djellison]

Also - it's worth noting that they were returned in the first few days of the rover's mission - at a time when it had the capability to return a lot of data, but not the capability to generate a lot of data as science instruments hadn't yet been checked out and they were not driving yet.

To add to the timing issue ( i.e. touchdown could have been +/- some tens of seconds ) there is also the opportunity to watch what happens after touch down - how long does it take for dust to settle, do pebbles roll around for a while, do we see any other impacts of EDL on the environment etc etc.

[mcaplinger]

All of the EDL thumbnails were returned in the first few days, and then selected full-res images in JPEG form, and then eventually in full-res lossless -- but the whole process took months. The last wasn't sent down until Feb-Mar 2013, and I don't think the post-landing images have ever been returned lossless (though I'm not sure myself, it's all in the PDS by now so someone could check.) The dataset I usually use only goes to shortly after touchdown.

There are many times when the rover is sending low-priority data because nothing higher is available, and most of this was sent that way, so any impression that this was starving out surface data is mistaken.

[yogi]

Thanks all for the comments! MahFL's comment explains why they were taken; although the "Assessment of the MSL EDL simulation" paper at

http://ntrs.nasa.gov/archive/nasa/casi.ntr...20130010129.pdf

sounds like most things went a lot closer to nominal than to need such a >= 2x margin, but I guess they didn't know that (not sure how many % longer the powered flight phase could have lasted - I know they had a lot of fuel margin, but surely not 2x?).

All of the EDL thumbnails were returned in the first few days, and then selected full-res images in JPEG form, and then eventually in full-res lossless -- but the whole process took months. The last wasn't sent down until Feb-Mar 2013, and I don't think the post-landing images have ever been returned lossless (though I'm not sure myself, it's all in the PDS by now so someone could check.) The dataset I usually use only goes to shortly after touchdown.

There are many times when the rover is sending low-priority data because nothing higher is available, and most of this was sent that way, so any impression that this was starving out surface data is mistaken.

Thanks, seems like my intuition of how precious the bandwidth was relative to that data was just way off - if there really was enough bandwidth available to downlink all of this without starving out any other data with even remote relevance then of course there would have been no reason to hold them back. I guess that was the main thing I was wondering - was there really nothing more important to transmit than > 3 1/2min worth of post-landing frames? And that relied on my mistaken assumption of how much other data there was waiting to be downlinked.

Re. "I don't think the post-landing images have ever been returned lossless", if with "lossless" you mean the 1646x1200px (1600x1200 with 2x 23px bars on either side) JPEG encoded .DAT images (which is the most raw format I've ever seen - is anything more raw available now?) then yes, all 1504 frames are available in that resolution/encoding; those are the ones I had downloaded from PDS.

[djellison]

. I guess that was the main thing I was wondering - was there really nothing more important to transmit than > 3 1/2min worth of post-landing frames? And that relied on my mistaken assumption of how much other data there was waiting to be downlinked.

The great thing about the priority system is that the rover figures out for itself what to downlink based on the predetermined importance of data at the time it's collection is sequenced.

[elakdawalla]

It's also worth noting that all the MMM cameras have their own internal storage (8GB each) for image data, so low-priority data can hang around for a long time until some adverse event happens that prevents the rover from acquiring new data but not from returning data to Earth, so the rover dips into a low-priority bin and sends back some time-capsule surprises. There are still pointer files on the main rover computer that keep track of all the images on the MMM cameras, so they still have to work to keep the numbers of files down.

Mike -- does each of the two Mastcams have 8 GB internal storage capacity, or does one 8 GB storage unit that cover both Mastcams?

[mcaplinger]

I guess they didn't know that (not sure how many % longer the powered flight phase could have lasted...

It's the time on chute that is uncertain. http://www.spaceflight101.com/msl-edl-reconstruction.html -- "For the Entry, Descent and Landing Sequence, the time under parachute was the biggest variable. It could have been as short as 55 seconds and as long as 170 seconds."

if with "lossless" you mean the 1646x1200px (1600x1200 with 2x 23px bars on either side) JPEG encoded .DAT images

JPEG is not lossless. Lossless after decompression is exactly what came from the camera head. At least the first ~650 EDL frames were sent lossless.

[mcaplinger]

Mike -- does each of the two Mastcams have 8 GB internal storage capacity, or does one 8 GB storage unit that cover both Mastcams?

The first. http://www.msss.com/all_projects/mmm-dea.php

[Deimos]

The thumbnails were, for the most part, down by sol 3 or so. Most of the JPEG compressed images were down within the first 6 weeks. Big chunks of them came down at a handful of times when communications passes massively over-performed the planning assumptions or when expected data ware not taken for some operational reason. While there was an ongoing attempt to pick and choose to get the best subset, the whole set became available.

Later, there was a trickle of lossless images--these are not JPEG compressed, except when they go to public web release. They are lossless on the PDS (and are 1648x1200, not 1648x1200x3). The lossless images comprise everything from the heat shield starting to get out of the way until around touchdown. I think I see 635 such images on PDS, with exactly one after the dust settled: images 27-660 and 1504. These, too, were frequently a buffer. Conservatively, you plan to get down all the surface data you need based on the low-end of the possible downlink volumes; but you make sure you have something good to take up the slack when things go especially well with communications or especially poorly with data acquisition (that oversimplifies, but is essentially the point). I imagine that for some of these images, they are on the ground because the rover's alternative was to send nothing.

[yogi]

Thanks everyone for the insights! I hadn't known about the onboard priority system, although it makes complete sense that the rover should have one rather than need to be told explicitly for every single item of data.

Deimos, where exactly do you see the uncompressed images? With your "1648x1200, not 1648x1200x3" are you saying they are grayscale? Thanks for correcting, BTW, 1648px wide is correct, my 1646 before was a memory lapse. I got my files from:

http://pds-imaging.jpl.nasa.gov/data/msl/M...R/SURFACE/0000/

Those files are all (*) color images in JPG format with some fixed size (64 bytes or so) header; My understanding was that "EDR" (Experiment Data Record) means "as unprocessed as available", so I figured there was no truly uncompressed format available (I know JPG is compressed, I figured perhaps you meant not processed any further). Seems like I was mistaken?

(*) except for the *C00_XXXX_00.DAT files which are in "PREP" format (not sure what that is) and seem to be grayscale.

PS. Not really relevant, but somehow I ended up with just 1503 frames rather than 1504, not sure where I missed one.

[Gerald]

...With your "1648x1200, not 1648x1200x3" are you saying they are grayscale? ...

Compare this rgb jpg of a compressed edr with this jpg of Bayer-encoded lossless edr image.
See also paragraph 4.4.5.3 of the MMM SIS.
8-bit lossless Bayer images are encoded by letter 'C' in the filename, see subsections 4.4.2 and 4.4.4 in the same document.

Edit: A lot more lossless images seem to be downlinked than currently available in the PDS directory you linked to, see JPL's MSL Raw Images website.

[Deimos]

The EDR is a faithful representation of what the vehicle sent. That may be a very compressed and downsampled thumbnail (check out the MER thumbnails). Or it may be a lossless image, a good JPEG image, or many other things.

As mcaplinger indicated, lossless images show what comes off of the array. They could be described as raw: they have been compressed, but what is archived has been uncompressed to the original. The CCD is 2-dimensional. If you work with such images, you have to do the interpolation to a color image your self, otherwise you see the Bayer-pattern of microfilters. The JPEGs have interpolation to generate 'new' information, followed by lossy compression to throw away information (to balance downlink volume vs. image fidelity required). The 'raw' format leaves you responsible for raw-to-color conversions.

The C00 and C01 files are lossless (via predictive encoding, pred). See Planetary Image Atlas (you seem to be looking at a single release of data), http://pds-imaging.jpl.nasa.gov/search/sea...tml#QuickSearch. Select MSL and then MARDI on the left. Select EDR for product type and set "0" for min and max planet day number. At this point, you can select "get count" and see lots. Switch to the product tab and put "C" in the Image ID field. Get count: 635 originals plus 5 retransmit products (C01) give you a count of 640. Get results, download images, and look up resources on de-Bayering.

(In the atlas, I see 1504 E01--JPEG, full--and 1504 I01--JPEG, thumbnail--products, but they may not have all made the cut for release 1, somehow.)

See Emily's blog for tips (and encouragement) for working with PDS data. Make a cool product

[yogi]

Ah, thanks! I hadn't known that the images were originally Bayer encoded which explains the grid pattern visible in the grayscale and even in the color images such as this one:

http://pds-imaging.jpl.nasa.gov/data/atlas...30E01_XXXX.jpeg

(I had noticed that pattern in the past, but had no idea what caused it). Thank you; and thanks for the guidance on how to navigate the PDS search interface!

I also hadn't known about Emily's Space Image Processing Tutorial [1]. Woah! Awesome! That'll help heaps in my quest to do cooler stuff with the PDS data (so far I've only made graphs of Mars elevation percentiles by latitude [2] based on MOLA data, and assembled the Mardi data into movies [3] that weren't as good as what other people had done before me).

I think I'll have to do some more reading on these forums to learn more before asking more questions. Thanks again, folks, for all the info and pointers so far. So much to learn - yay!

[1] http://www.planetary.org/explore/space-top.../tutorials.html
[2] https://plus.google.com/+TobiasThierer/posts/8XZGx1PoQBg
[3] https://www.youtube.com/playlist?list=PLb_w...ddHenL7_HH65nYP

[Herobrine]

I hope you'll forgive this blast from the past, but I only recently learned that the real raw image data (as opposed to the artefact-ridden JPEGs NASA calls "raw images" on their MSL site) is available elsewhere, and I've been having a field day playing with it.
I made an animation of the heat shield impact, using the raw MARDI image data. I think we've all seen animations/videos of the impact before--NASA released one of their own--but I'd never seen one nearly as clear as this, and unless my forum search skills are lacking, I don't see one posted here, so here it is.
No synthetic interpolation or anything, and certainly not real-time. This is made from frames 330 to 359.
Hosting on imgur because it's over the upload limit.

The GIFing brought the quality down a little bit, but it's still better than what I've seen before.
It follows the heat shield up until impact. The shadow is visible for 4 frames or so, prior to impact.

On a related note, I'm really happy with what I can see by processing the raw MARDI image data that I couldn't begin to see when I was working with the "raw images" from NASA's MSL site.
http://mars.jpl.nasa.gov/msl-raw-images/ms...0559E1_DXXX.jpg
vs
http://i.imgur.com/xIhWO7b.jpg (contrast exaggerated, obviously, though not intentionally; it's just a typical result of the scaling that's done to get the data back to 8-bit-per-channel in my processing)

Edit: It occurred to me that some people might not appreciate a 2 megabyte GIF embedded directly in the forum, so I added a clicky thing.

[James Sorenson]

Very well done! I made an attempt awhile ago at this with PDS imagery, with no enhancement.
https://www.flickr.com/photos/43581439@N08/...659985/sizes/o/

[yogi]

Awesome job! Where did you get that raw imagery? I got the EDR .IMG files from PDS [1] but they were essentially JPG files after a 64byte header. I'd love to have the better data!

[1] http://pds-imaging.jpl.nasa.gov/data/msl/M...R/SURFACE/0000/