If you look at http://naif.jpl.nasa.gov/pub/naif/JUNO/ker.../fk/juno_v08.tf you see that the true camera frame JUNO_JUNOCAM is rotated by 0.69 degrees around Z relative to JUNO_JUNOCAM_CUBE, but this rotation should be mostly cancelled in the transform from cube to spacecraft -- at least, that's what we were trying hard to have happen. I haven't tried to convert the matrix for the latter back to Euler angles.

I don't think you can correct mismatches from translation by rotation. Since you seem to be getting good results by assuming the spacecraft position is wrong, maybe it really is wrong. I haven't been able to figure out the pedigree of the orbit determination for the flyby to be able to assess if errors could have crept in, and I wasn't 100% sure how to compare your trajectory to the SPICE-reported one because you seem to have a sign difference and a time reversal in your processing, but they seem to be different by 10s of km.

This thread has a good chance of degenerating into unrealistic speculation. Rather than comment, I think I'll just quote what user "Jim" over at NSF said:

Could you describe what this looked like? Obviously errors in position could explain the mismatches, but I've always assumed that the reconstructed SPICE trajectory would be extremely accurate in the Earth frame, and this implies that it might not be.

Pallas is too inclined to the ecliptic to reach. From http://dawn.jpl.nasa.gov/mission/faqs.asp, Marc Rayman says



BTW, you can't do effective gravity assists from small bodies. See "Tethers and asteroids for artificial gravity assist in the solar system", http://arc.aiaa.org/doi/abs/10.2514/3.25086?journalCode=jsr

If you're happy I'm happy, but it seems like an awful lot of work for something with not a lot of practical utility to me.

You only need the optical depth if it's changed significantly between the images you're trying to compare, otherwise since you are only computing a relative albedo it doesn't matter how it might be scaled. And there are all kinds of secondary effects from the brightness distribution of the sky, and in the near field, light reflecting off the rover, that I think you're ignoring. Though I'm not sure how large those effects are.

As to how you compute the optical depth in the first place -- obviously you start by looking at the levels in the sun images and normalizing them to absolute radiance units. I have to confess that I glazed over a bit while reading the discussion of what happens next in, e.g., http://arxiv.org/abs/1403.4234 -- and a lot of the described MER processing is unneeded for MSL, or at least different.

You might consider trying to do what you're trying to do for the time period for which there are published optical depths. See, e.g., http://www.hou.usra.edu/meetings/8thmars2014/pdf/1338.pdf

I expect you'll find that the optical depth measurements don't really solve your problem, but I could be wrong.

MSSS TAGCAMS Camera System Performs Well in Thermal/Vacuum Test

http://www.msss.com/news/index.php?id=124

I don't know of any product that compensates for time of day. Radiometric correction is just making the conversion from pixel value to absolute radiance unit. Since sun angle varies wildly over the scene regardless of the time of day, how are you going to correct for that in general?

If you have to mosaic images taken at different times of day (which are problematic for other reasons, shadows don't match, etc) you have to use some kind of empirical matching technique.

I presume you're saying it's "not true" that it's early to worry about this. The Atlas launch manifest is a matter of public record. Next launch is MUOS-5, which was slipped from 5 May to 12 May for the OA6 anomaly investigation. I wouldn't expect that week to ripple forward all the way to OREx. http://www.spaceflightinsider.com/organiza...muos-5-mission/

If you have an actual source of information that says this is a concern, post it. The spacecraft won't be mated to the LV until about a week/10 days before launch if the Juno experience is any guide.

BTW, http://forum.nasaspaceflight.com/index.php?topic=39920.0 is the best source of information on the Atlas anomaly that I'm aware of.

There are three Atlas V launches on the manifest before OREx, so it's a little early to worry about this. Worst-case, my understanding is that OREx has a backup launch window in 2017, but obviously using it would be very undesirable for cost reasons.

Again, I'm not really sure what you're trying to learn in general. I'm sure you're aware of the series "Chronology of KSC and KSC-Related Events" that can be found on NTRS. It varies widely in level of detail but, for example, from the 1992 issue we learn that Mars Observer was initially delivered to Hangar AO in June 1992, moved to PHSF in July, and then went out to LC40 in August. It got contaminated by particulates during the passage of Hurricane Andrew in late August and had to be taken back to PHSF to be cleaned (that was a lot of fun, I can assure you) and then it was taken back out to LC40 and launched on September 25.

I'm not sure exactly what you're looking for, but I think you'd be more likely to find it at http://forum.nasaspaceflight.com/

All the NASA missions I've worked on (except perhaps for Mars Observer, I can't remember) have delivered their hardware directly to PHSF or SAEF-2 (or Astrotech).

There's a photo of Pioneer 10 on its upper stage linked from the wikipedia entry. https://en.wikipedia.org/wiki/Pioneer_10#/m...s_kickmotor.jpg

I don't recognize the facility. As far as I know, PHSF wasn't even built until the mid-1980s.

If the target illumination conditions (solar distance, phase, etc) are the same, then the only way the images can have different levels is if there's something else going on, like different gain settings (what a typical consumer digital camera calls "ISO".) You have to know all of these settings to get images that can be directly compared.

Our cameras on MRO, LRO, MSL and Juno don't have gain settings, but some of our other cameras do (e.g. our cameras on OREx).

The point of some radiometrically-corrected PDS products is to have images that have such variations removed somehow by appropriate scaling.

So in my post above you read "The MSL team sometimes uses "Mount Sharp" in publications, but it's never going to be an official IAU name" as "it's never going to be an IAU IAU name"? Yeah, that seems helpful.

What does "too late" mean? The MSL team sometimes uses "Mount Sharp" in publications, but it's never going to be an official IAU name. The NH team uses their names in LPSC abstracts, with a caveat of "all feature names here are informal". I expect we've got a few hundred years at least before the names of surface features on Pluto are of more than academic interest.

I suspect the lack of progress is a mixture of the general slowness of the process and some real controversy. Perhaps surprisingly, the IAU seems to have blessed the use of Charon as the home of sci-fi names. On the other hand, some of the NH team's suggestions are likely never going to be approved by IAU because they simply don't fit with the established naming conventions.

http://www.geekwire.com/2015/pluto-we-have...ly-on-iau-maps/

I'd guess this has been discussed ad nauseum on other threads.

Other than the general categories, I don't see anything at http://planetarynames.wr.usgs.gov/ about official Pluto nomenclature.
See https://www.iau.org/public/themes/naming/ for a description of the process.

You don't have to guess, it says right on the page if the LEDs are used. E.g., http://mars.nasa.gov/msl/multimedia/raw/?r...DXXX&s=1272

"When Curiosity acquired this image, the group 1 white light LEDs were on, the group 2 white light LEDs were on, and the ultraviolet (UV) LEDS were off."

The same page gives the motor count from which you can determine the cover state.

If you're going to say that their product is "almost useless" it only seems fair to give them an opportunity to fix it or at least explain what the issue is.

Have you tried contacting the EPIC team about what errors you are seeing in the quaternions?

As you point out, doing a comparison with the doubly-compressed public release Mastcam JPEGs isn't really fair, especially if they have to be interpolated from their JPEG form. (Though I acknowledge that this is a problem of our own making.)

The M100 images taken on sol 1240 were sent predictive. Alas, I can't show you those products, but they obviously look a lot better than the public versions. But I would have to admit that the RMI images are at least 2x higher resolution in this case. Of course, with an aperture of 110 mm they really should be.

Nice job. It would be interesting in some of these cases to show the RMI mosaic and the Mastcam mosaic at the same scale rather than shrinking the Mastcam mosaic down. Because of the relatively low MTF of the RMI, I think its advantage over Mastcam is not as great as these sorts of views might suggest, especially if you sharpen both products equivalently.

BTW, I ran across this technical description of JIRAM -- http://www.ifsi-roma.inaf.it/jiram/downloa...Tech%20note.pdf -- that has some detail about how the instrument works. Its IFOV is about 2.8 times finer than Junocam's, so at JOI-5d Jupiter should be about 112 pixels across.

I haven't seen any inflight imaging from JIRAM yet. According to http://www.lpi.usra.edu/opag/jul2013/prese...o_efb_plans.pdf images were supposed to be taken of the Moon during EFB.

Is the georeferenced CUB version online anywhere? Maybe USGS should be using that since it's so much better than the original version.

Given how well this worked, I'm surprised no one has gone back and reprocessed the whole C1-MIDR dataset like this. There's this -- http://www.celestiamotherlode.net/catalog/...p?addon_id=1070 -- but I haven't looked at it.