Juno Earth flyby is coming up on 9 October. Junocam will be taking a handful of images near closest approach (Earth isn't in our FOV for most of the flyby.) We expect to be putting the images out on the web as soon as we receive them (the details of exactly how and where are still being worked out.)

To let those of you who might be interested in processing the raw data get a head start, here is a simulation of one of the best color Earth images. As described elsewhere, Junocam is a pushframe camera with an 11mm focal length, 7.4 micron pixel pitch, and an FOV of about 58 degrees crosstrack, with four spectral bands (red/green/blue and 889nm CH4 absorption band). It uses the 2 RPM spin of the spacecraft to sweep out the target. This simulated image has 82 frames of 3 framelets in blue/green/red order top to bottom (each framelet is 1600x128 pixels). The SPICE files used were spk_ref_130515_171017_130515.bsp and juno_sc_prl_130726_131020_jx024a02_EFB_v03.bc; the first frame was taken at ET 434617745.182 (10/9/2013 19:08:00 UT) and the interframe time was 0.370 sec.

Simple processing can be done by rearranging and color-stacking the individual strips, but that will leave you with some color misregistration due to spacecraft motion, lens distortion, etc. Doing something better is left as an exercise, and I am interested to see what people come up with.

Note that this is a simulation. The real data may look much worse than this; one major concern we have is the amount of interline transfer smear, because we have to use a much shorter exposure time at Earth than the instrument was really designed for.

The archived SPICE data at http://naif.jpl.nasa.gov/pub/naif/pds/data...log/spiceds.cat says



I haven't looked to see if the archived data for sols 0-179 are any different/better than the quick-look products that Joe is using.
We are only talking about a %4 difference, and no telemetered value is going to be as accurate as one determined by ground
photogrammetry.

Eyeballing what? Hopefully not the image in my previous post, which is in the Earth-fixed frame and is probably misleading.

Energetically it doesn't make sense to go out of the plane of the ecliptic.

Subtracting a constant color is just equivalent to a stretch and color correction. It might be that the dust scattering varies across the field, but it doesn't look like it to me, at least not strongly.

I've gotten OK results by just auto-white-balancing the image and then stretching it a little, since all the dust is doing to first order is tinting the image and reducing contrast. It's a little out-of-focus because MARDI is focused at infinity, and a light high-pass might help that if you like that sort of thing (I avoid high-pass whenever possible because it boosts noise, compression artifacts, etc., but that's mostly a matter of taste.)

True, but one has to use orbital elements with some caution because, as Jason points out, they could be given in any defined reference frame. Most often orbital elements are stated in the "Mean Equator and IAU vector of J2000" frame (see, e.g., http://naif.jpl.nasa.gov/pub/naif/toolkit_...mes.html‎ ) but the nice thing about using NAIF/SPICE SPK files is that you can state the frame you want and the software makes any needed transformation to give it to you.

Often when orbital elements are supplied it's not stated what the frame is, and in those cases one would have to make assumptions -- one reason why I don't like using elements if I can avoid it.

"mean equator" has to be used because of precession and nutation; the spin axis of a planet is always moving, albeit slowly.

How lengthy or costly do you think it was? I believe that most of the work to qualify the MMRTG was done long before MSL. You can get more insight into this by reading http://science.nasa.gov/media/medialibrary...L-FEIS_Vol1.pdf

At any rate, those are the rules.

Read the SDT report and the FAQ at http://mars.jpl.nasa.gov/m2020/

"No final decision on a power source for the 2020 rover would be made until the mission completes a review
through the National Environmental Policy Act process, which considers the environmental impacts of launching
and conducting the mission. This process is currently scheduled to conclude in late 2014. The baseline-design
power source for 2020 mission planning is the same as Curiosity's: a multi-mission radioisotope thermoelectric
generator. Other possible power sources are also under consideration, including solar power."

We have no involvement in MAVEN, which has no camera.

A quick web search found
http://www.lockheedmartin.com/us/news/pres...al-testing.html

"MAVEN is scheduled to ship from Lockheed Martin’s facility to NASA’s Kennedy Space Center in early August"

http://www.lpi.usra.edu/meetings/marsconce...4267.pdf‎ has some (not-entirely-consistent) numbers in it.

I'm not sure I would believe everything you can find about smallsats -- a lot of blue-sky hype in that area, not so much real engineering. A summary article that just echoes a lot of marketing fluff is not that valuable IMHO.

http://www.nasa.gov/news/media/newsaudio/i...ml#.UdsrNHZ385a

Tuesday, July 9 at 3 p.m. EDT: NASA Teleconference on Mars 2020 Plans

NASA is hosting a media teleconference to provide details about a report that will help define science objectives for the agency's next Mars rover.

The report, prepared by the Mars 2020 Science Definition Team (SDT) NASA appointed in January, is an early, crucial step in developing the mission and the rover's prime science objectives.

I'm not sure what your point is, because this is a MER thread.

img2png -- http://www.unmannedspaceflight.com/index.php?showtopic=4979

Mariner 10 or Messenger flyby imaging is probably more accessible than PV data.
http://pds-imaging.jpl.nasa.gov/volumes/mess.html for Messenger.

Because TETR was octagonal and this has more faces.

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.

One article in Icarus doesn't constitute a fundamental change in scientific "opinion" -- and I'd like to believe that science is not about opinion anyway.

These hypotheses are always worthy of consideration, but testing them may not be possible without more data.

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: 609


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.

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.

These files have detached labels; the IMG file has no label information. I don't know how the ImageJ plugin works, but possibly you need to open the LBL file rather than the image file?

For example, I just looked at http://pds-imaging.jpl.nasa.gov/data/msl/M...959E02_DRCL.IMG and LBL and this is a normal, 8-bit, band sequential RGB image with 1646 samples and 1198 rows (don't ask me where those image dimensions came from, something to do with removing some of the dark pixel columns or something? I had nothing to do with it

The only program these were tested with, AFAIK, was NASAView: http://pds.jpl.nasa.gov/tools/release/software_download.cfm

I had nothing to do with the software development, but I'll try to look at this when I get a chance. But any solution I come up with will likely be based on the Python Imaging Library.

It's legal jargon that PDS uses (inappropriately, IMHO) to indicate that there are issues associated with the dataset that they are awaiting correction of. In this instance I think these were all addressed in the volume errata files. Since they put the datasets online it doesn't really matter.

BTW, the simplest way to use the archive products would be to stick with the EDRs, which for all JPEG compressed images (the vast majority) just consist of the JPEG data as we received it from Mars, with a simple header containing critical metadata at the beginning. I'd use only that metadata to get the SCLK, exposure time, filter, and other image parameters (ignoring the detached label), and continue to use the SPICE data for all the pointing information. IMHO getting the other metadata from the MMM archive products isn't going to be any better than using SPICE, but will likely be harder, especially if you've already written SPICE code.

Depending on what you're trying to do, doing your own processing might be as easy as using the RDRs, but that's a determination you have to make for yourself.
All of the information we use to make RDRs should be on the volumes.

From http://pds-imaging.jpl.nasa.gov/ "The Imaging Node is pleased to announce the release of Mastcam, MAHLI, and MARDI EDRs and RDRs for Sols 0-179."

http://pds-imaging.jpl.nasa.gov/data/msl/M...R_RDR_DPSIS.PDF would be a good document to read first.

You say "in principle" a lot in this post, and I don't disagree.

That said, there is no display device I can think of that can come anywhere close to reproducing the brightness of the spectral radiance of a sunlit scene. Possibly if you printed up a huge billboard and put it outside in sunlight, ignoring issues of color printing accuracy, the BRDF of the medium, etc, etc, etc.

At any rate, these cameras aren't spectrometers, they only measure signals integrated over three spectral bandpasses roughly designed to mimic the human tristimulus response. They will give you a better sense of what the scene might look like than the narrowband filters used on MER, but that's about as far as I'll go.

This topic is both very technically nuanced and ultimately subjective, to the point that if I were running this forum, there would probably be an explicit rule against discussing it.