MSL data in the PDS and the Analyst's Notebook, Working with the archived science & engineering data Options

[mcaplinger]

But I thought it was the same Navcam as on MER. And so they could be open the same way. Can't tell what seems to be the problem…

Looking at the source at http://rsbweb.nih.gov/ij/plugins/download/PDS_Reader.java , it appears that the plugin (from 2001) requires there to be a SFDU label in the data product. These were required a long time ago, but aren't any longer. "The PDS does not require Standard Formatted Data Unit (SFDU) labels on individual products." Seems like some updating of the plugin is required.

[Ant103]

Okay :/

This is sad because this plugin was simple, opened the files in 16 bits, and with ImageJ it was cool to export it in png with 16 bits.

I guess, I'll have to find an other way to handle MSL data (maybe try this NASAView software, but as far as I can recall, I've already tried it and found it not very convenient to use, and it's an online tool I believe, so exit the reading of local files).

Edit : I've downloaded NASAView, and yes, it can open local files (I mistooken it with an other software). So now, the challlenge is to apply the right color scheme. Because I'm opening an LBL files, and I have a window that suggest me to enter value for each R, G and B "layer" of the Bayer matrix (I think).

Edit 2 : Opening Mastcam. Check. Find the good values for the LBL file. Not quite. Save the result as a Jpeg file. Not very good. It leads to a greyscale images with vertical bands all over the image. And with Navcam images, the Jpeg export lead to a stretched picture. Not the thing I'm looking for when working with IMG files…

Edit 3 (and this will be the last) : I'm reading on http://pdssbn.astro.umd.edu/tools/software.shtml this line about NASAView : "The program is not intended to be used for saving and intensive scientific analysis of the data.". As well I'm not a scientist, I quite like an high quality imagery. So, NASAView is not the droidsoftware I'm looking for.

Edith : An interesting reeading here about a modifyed version of the ImageJ plugin. http://www.marsroverblog.com/discuss-20354...sicspage14.html It seems to working well with MSL IMG files . I managed to download the .java source file, and copy / paste the new code. I succeed to compile it. I will try with Navcam files.

[mcaplinger]

This is sad because this plugin was simple, opened the files in 16 bits, and with ImageJ it was cool to export it in png with 16 bits.

Someone who knows how to compile Java in a platform-independent manner could fix the plugin in about 5 minutes, I suspect.

Attached is a simple Python script that reads these files and saves them out as PNGs, but if you don't have Python and PIL installed on your system, that won't do you much good. Also, PIL can't save a 16-bit-per-channel RGB image, so the 16-bit forms of the RDRs would have to be managed as separate channels. For this version, I convert 16-bit data back to 8 bits.
 pdspildet.txt ( 1.56K ) Number of downloads: 581


Of course, I hasten to point out that if you want to use the RDRs, saving them out as JPEGs is losing information, since they were JPEGs to begin with as transmitted from Mars.

[Ant103]

Okay, this new PDS Reader plugin for ImageJ run like a charm .

Here a Sol 2 Navcam image.

Attached thumbnail(s)

 

[mhoward]

Thanks for all the tips on this. One thing I'm wondering is if any files are duplicated between, for example, the MSLMST_0001 and MSLMST_0002 directories, and if so, are the contents of the files the same or different. (I'll probably find out the hard way before too long.)

[PaulH51]

Okay, this new PDS Reader plugin for ImageJ run like a charm .
Here a Sol 2 Navcam image.

Looks crisp... Can you point us to the original 'raw' file name for this image (prior to calibration)? Or if that is not possible then its current file name in PDS.

TIA

[mcaplinger]

One thing I'm wondering is if any files are duplicated between, for example, the MSLMST_0001 and MSLMST_0002 directories, and if so, are the contents of the files the same or different.

There are certainly instances where we have transmitted the same image with different compression types or quality levels (for example, the MARDI EDL images were initially transmitted as JPEGS of one quality, then a subset were retransmitted with higher quality, and eventually as lossless versions.) Also, I wouldn't be surprised if some files got archived in partial form (data missing at the end) and then later in complete form, although those arguably should have been weeded out in the archiving process. If you see anything that looks confusing, let me know by PM and I'll pass anything I don't understand on.

[Ant103]

Yes Paul

http://pds-imaging.jpl.nasa.gov/data/msl/M...AUT_04096M1.IMG

[fredk]

Edith : An interesting reeading here about a modifyed version of the ImageJ plugin. http://www.marsroverblog.com/discuss-20354...sicspage14.html It seems to working well with MSL IMG files . I managed to download the .java source file, and copy / paste the new code. I succeed to compile it. I will try with Navcam files.

Thanks for the tip, Ant. I get an error message when I compile the new PDS reader:

CODE

C:\Program Files\ImageJ\plugins\PDS_READER_NEW.java:10: Public class PDS_Reader_New must be defined in a file called "PDS_Reader_New.java".
public class PDS_Reader_New extends ImagePlus implements PlugIn {
             ^
1 error

Did you have this problem?

Edit: Fixed. The filename needed to be "PDS_Reader_New.java", with mixed upper/lower case. Works great now.

And thanks to Horton, if you still read here...

[Gerald]

A list of APXS targets, first 180 sols:
 apxs_summary_targets_sol_0_179.txt ( 4.01K ) Number of downloads: 505


CSV-file (for spread sheet software) containing according weight percent (rwp) data:
 apa_rwp_Sol_0_179_comma.txt ( 8.3K ) Number of downloads: 697


Graphical synopsis:


The above data and graphics are derived from data provided by this PDS subdirectory.

[Greenish]

Nice, Gerald. Here is MAVOR, the one from Sol 158 that is the obvious outlier in terms of way more SO3 content. Distances are from the daily uplink notes.
context 25cm http://mars.jpl.nasa.gov/msl-raw-images/ms...1000E1_DXXX.jpg
closeup 2cm (focus merged) http://mars.jpl.nasa.gov/msl-raw-images/ms...0006R0_DXXX.jpg

(edit, fix link to full image not thumbnail)

[Gerald]

Thanks, Greenish!

Mavor APXS data are consistent with most of the sulfur being bound to calcium sulfate. But there seems to be a small excess of sulfur:

CODE

28.8  (g SO3/100g) / 80 (g SO3/mol) = 0.360 mol / 100g,
18.95 (g CaO/100g) / 56 (g CaO/mol) = 0.338 mol / 100g,
excess of SO3:                        0.022 mol / 100g.

PDS data source in file apa_411516167rwp01580051954_______p1.csv in this PDS subdirectory.

[Gerald]

For convenience, here the PDF version of the MSL mission summaries for sols 0 to 179:
 MSL_Mission_summaries_sol_0_179.pdf ( 55.73K ) Number of downloads: 945

It can be obtained via Analyst's Notebook:
Follow the link "Historical overview", then "Download as PDF".
Print the page, redirected to saving as PDF file.

[Gerald]

The elemental composition determined by APXS analysis is derived from APXS spectra.

Two examples of APXS spectra:


They show the rsp files apa_401575435rsp00460042100_______p1.csv (this PDS directory for sol 46 APXS RDRs) and apa_411516167rsp01580051954_______p1.csv (this PDS directory for sol 158 APXS RDRs) as diagrams.

Transforming the x-ray photon energy (in electron volt) via
Z = sqrt(eV / (0.75*13.6057))+1
simplifies the identification of the K-alpha spectral line with the atomic number of the respective chemical element:

(See Wikipedia about Rydberg constant, Lyman-alpha line, and Moseley's law)

Note the peaks at K-alpha for atomic numbers 16 (sulfur) and 20 (calcium) in the Mavor spectrum.

Although some of the x-ray emissions aren't K-alpha.

A comparison of Ekwir_1 (29896 seconds counting time) with Snake river (1330 seconds counting time) shows, how counting time influences data quality (logarithmic scale for the counts):

[Gerald]

Here an annotated version of the Ekwir_1 APXS spectrum:

I've been trying to find the most plausible x-ray emission lines the above spectrum is composed of without using sophisticated optimization software.
It may provide a rough idea of how APXS data can be analysed. Besides the K-alpha spectral line the K-beta line(s) occur, particularly for calcium (Ca) and iron (Fe). For the peaks between 4.6 and 5.0 keV I didn't find a fully plausible explanation; the peak near 22.2 keV is close to K-alpha of silver, and occurs also in pure SiO2 calibration data.
For Rayleigh and Compton backscattered x-rays plutonium emission lines are relevant, because curium used by APXS decays (partly) to excited plutonium, which releases x-ray photons when returning to the ground state. The Rayleigh component occurs close to the originally emitted photon energy, the associated Compton spectrum is in an energy range a little below.

A summary of APXS as used by MSL can be found in the MSL science corner.
Detailed data about X-ray transition energies can be queried via NIST.
Technical and physical background about X-ray spectroscopy can be found in this IAEA paper.
This LPSC 2008 paper provides an idea of how light elements can be inferred by comparing Rayleigh with corresponding Compton backscattering when the preliminary elementary composition is known.
The recommended document for APXS calibration is behind the paywall.