Curiosity Image Retrieval Tools, scripts and software Options

[CosmicRocker]

... Anyway, here it is, Curiosity RAW Get. ...
UPDATE:
I was getting too many strange errors using the Microsoft HTML parser. I've now switched parser. Anyone who's had trouble with earlier versions would do well trying this new one.

Although I had some problems with the first version, the new one (0.13) is working quite well for me. It seems to be a good option for Windows users who want to download MSL images in mass. The application allows you to apply various filters to your selection, and it automatically creates a nice directory structure.

[djellison]

I have no idea who's in charge of the website.

Michelle Viotti

[jmknapp]

I'm on the camera team and I'll complain about it if I want to, thanks.

That said, this is kind of an interesting article.
http://www.informationweek.com/government/...web-s/240005286

In this case, the fix is dead simple--the thumbnails do exist. If they just change the 'E' to 'I' in the img src file names they'd be done. Straight bug fix, not a feature request. Until that happens, anyone scraping the web pages for URLs should be aware.

I guess Amazon Web Services would give a big thumbs up to the current situation though!

[M_Welander]

...Veronica McGregor... ...said that they officially do not care about bandwidth since everything is stored in the cloud.

That's very good to know! I guess that means I can safely enable the threaded downloader in Curiosity RAW Get without risking to hurt their servers, then.

[algorimancer]

I have my AlgorimancerPG rangefinder/photogrammetry tool updated to work with the MSL navcam images -- I hope to post it to the website tonight (it's not there yet). I'll announce the availability here when I do (this seems the closest topic match in the MSL section).

One thing it is lacking is the correct sol/time calculation; it will display a value, but it's not going to be a correct value. If someone could clarify how to get the sol/time from the image title, that would be much appreciated.

Another thing lacking is camera orientation. For MER, this could be obtained from the Pancam Tracking Database. I'm not aware of any such database as yet for MSL.

Support for the Mastcam's higher resolution cameras may or may not happen for MSL, as this will require rather more time than I happen to have at the moment. If there's someone with experience programming with Microsoft Visual C++ (Visual Studio 2010 professional) who would like to take-on the project, particularly someone familiar with imagery and vectors and quaternion transformations, I would be happy to share the code. This may take anywhere from a few days to a couple of weeks of programming time. Considering that we have high resolution images and topography from orbiters already, I'm not sure there would be much value in adding Mastcam capability, but it is an option.

[mcaplinger]

If someone could clarify how to get the sol/time from the image title, that would be much appreciated.

Another thing lacking is camera orientation. For MER, this could be obtained from the Pancam Tracking Database. I'm not aware of any such database as yet for MSL.

For Navcam the file name has the SCLK value for the image time, I think. For MMM it appears there is no SCLK in the filename and metadata would be needed to figure out the time. I'm not sure what the time on the raw image website means, I haven't tried to correlate it.

The NAIF website (http://naif.jpl.nasa.gov/naif/data_mars.html) has some information about how to map SCLK to UT and LMST and may be a source for pointing data (I'm not sure what the CK files there look like or what their plan is to update it.)

[ugordan]

I'm not sure what the time on the raw image website means, I haven't tried to correlate it.

I think it's just SCET.

[jmknapp]

I'm not sure what the time on the raw image website means, I haven't tried to correlate it.

I've checked it--for example the website has FLA_397506083EDR_F0010008AUT_04096M_ with a time of 2012-08-06 06:23:34 UTC.

From the file name, the et is 397506083, which according to et2utc_c() translates to 2012 AUG 06 06:20:16 UTC. So there's a discrepancy of about three minutes (3:18). Possibly related to processing on the rover?

Just for another example, here's one from sol 2, NLA_397682534EDR_F0020000AUT_04096M_--the date given is 2012-08-08 07:24:27 UTC and 397682534 translates to 2012 AUG 08 07:21:07 UTC, similarly a 3:20 difference.

[mcaplinger]

From the file name, the et is 397506083...

My guess is that this is not ET but SCLK, which drifts from ET. You need to use scs2e (or sct2e) to get this into ET.

[algorimancer]

...The NAIF website...

Thank you, I think that did the trick.

EDIT: I've run into some difficulties with the installer (upgrading the development environment from VS 2005 to VS 2010 has been a real headache). Hopefully I'll be able to fix it tomorrow and get it posted.

[jmknapp]

My guess is that this is not ET but SCLK, which drifts from ET. You need to use scs2e (or sct2e) to get this into ET.

Sounds reasonable--but isn't SCLK measured in 'ticks'?

[mcaplinger]

Sounds reasonable--but isn't SCLK measured in 'ticks'?

You don't get the subseconds in the filename, so you will be off by a second minus a tick worst-case.

[jmknapp]

Trying to develop a handier web interface to the raw images, here's a first go if anyone would like to help beta test it:

http://curiositymsl.com/table/view

It shows the raw images in table form, sortable by date taken, release date, etc. by clicking on the column headers. The default sort, by release date, is the handiest I think, since it shows the most recent uploads to the JPL site. It's hard otherwise to keep track of the newest files because they can come in under any sol.

Open to suggestions as to how it could be more useful. One thing that comes to mind is to be able to filter by camera, because with all the images in one big list, there are a lot of pages, mostly due to the large number of MARDI images.

[elakdawalla]

First: AWESOME!

It would be great to filter by camera.

I think image dimensions would be more useful than file size.

I'm amused by the "lag" column, though it's not exactly fair, since it folds in both transmission lag (when did it arrive on Earth?) and raw posting lag.

I'd prefer smaller thumbnails and more images per page, but don't know if that opinion is shared.

This takes more logic, but: it would be great if it did not show *both* thumbnails *and* fulls of the same image. It would be lovely if it could just show the highest-resolution one returned to Earth so far.

[Guest_Oersted_*]

Works great on a Samsung Galaxy Nexus smartphone, for what its worth... -Excellent job!