This particular image was part of a mapping operations test. Since it has a short exposure, it likely doesn't show any real objects, just noise.

We didn't take any RGB images of stars and the zodiacal light. We took some red and some green with spectral crosstalk because the amount of TDI was longer than the frame height would support.

As for processing the IMG files, there's a saying about giving a man a fish, I don't quite recall how it goes.

One nearly always uses ET, not UT1. I just call NAIF utc2et and let it worry about the details.

If these are from the EDRs, then it's because there is no color correction in the camera and it just worked out this way between the filter bandpasses and the sqroot encoding. If they were from the RDRs with the band scaling applied, it's because the scaling is slightly off, which would not surprise me.

For the EFB images, since the Earth's clouds are basically white, an auto white balance works fine, though a color purist might object.

I have updated six of the EFB images at http://www.msss.com/junocam_efb/pds/ that were decompressed incorrectly. These are 00C096, 00C098, 00C100, 00M095, 00M099, and 00M103. The rest of the EFB dataset should have been correct.

These are not official products, have undergone no QC or review, I'm not promising the label information is even as accurate as it was the last time, etc. But the image data itself should be better.

I have no idea, I'm not even sure at this point who's participating in the outreach press briefing or what it will cover. I'd think that EFB images might have a certain potential for media confusion ("if we're arriving at Jupiter what are these images of the Earth?")

That said, I've been told that the preferred video product in general is a 1280x720 pixel 59.94 fps Quicktime ProRes HQ codec Quicktime movie.

This is the wrong thread for this discussion.

From Emily's writeup http://www.planetary.org/blogs/emily-lakda...om-junocam.html :

I have every expectation that our standard-processed map-projected products will be available as soon as we have reconstructed spacecraft attitude information, 2-3 days after each perijove. Assuming of course that the perijove pass is nominal and the data are downlinked without gaps, etc.
As with EFB, it may be that amateur-processed products that are more manual and labor-intensive will be better than our automatically-generated ones.

BTW, when the missionjuno website says they are posting the "raw data" I am not at this point 100% certain what they mean. That said, I'm sure that the raw data will be available somewhere.

Don't waste your time with this. The fix has been known for some time and all I need to do is rerun the processing for these products; I'll try to get that done next week. I'd have done it before but honestly I think you are the only person in the world who has ever looked at these files.

"Notional" means they haven't decided yet.

I think it's believable that they said they would use this hardware. Since I design and build space cameras for a living, you can likely predict how I feel about using a $300 commercial camera in such a context.

http://ippw2016.jhuapl.edu/docs/abstracts/...rumentation.pdf page 18 has the system description but not the specific details.

I wasn't at this conference but it seems unlikely that someone would just make this stuff up.

I think that's a step in the face of the cover, not a color difference, but I could be wrong.

I don't see what you're talking about. As far as I know all of these targets were used for arm checkout and don't have any ongoing operational role, but I could be mistaken.

To be clear, I don't think there was ever adhesive of any kind. I think the original white pattern was some kind of paint/marking ink (probably epoxy-based, that's what we use for labeling) that was stripped off when the cover was re-anodized.

If you look at the original M34 raw images taken in the system thermal test (sorry, can't share), you can see that the background color is identical to the cover's, so there is no backing surface as far as I can tell at the resolution of the image. It looks like a cut decal, very conformal to the cover.

I don't know more about the story of this target, but I have some inquiries in.

[EDIT]
Ah, the full story. The covers were originally black-anodized but were found to be flaking ( http://llis.nasa.gov/lesson/8403 .) Seems like the original white target got stripped off when the covers were reanodized but there was some residual etching and that's what you're seeing.

http://www.unmannedspaceflight.com/index.php?showtopic=5079

If the deflection angle is about 2 arc-min per that thread (assuming I haven't made a units conversion mistake), then that would be about 100 LORRI pixels, so yeah, it should be in there somewhere, though there would be some motion of Pluto against the star background even if there was no deflection and even without the barycenter thing.

BTW, MOC and HiRISE have smaller IFOVs than LORRI, so your "smallest yet flown beyond LEO" is wrong.

Um, no.

If they don't start reusing them then there wasn't much point in getting them back, was there?

I don't think so. It's a percussive drill being driven open-loop, so there's only very coarse telemetry. See
http://www.esmats.eu/amspapers/pastpapers/pdfs/2010/okon.pdf

All of the MSSS cameras are electrically identical from the detector back and all of the ground calibration was done in basically the same way, so it's a safe assumption that the processing was as similar as it could have been.

Mods: you might consider moving this part of the discussion to the MSL cameras thread, as the intent of this thread was "hypothetical near-future rovers".

Have you read all of https://www.researchgate.net/publication/27...ibration_status including the supplemental data file?

Maybe I should start a thread about my dream list of what I want from the amateur community.

Can be done for the engineering cameras, does not exist for Mastcam/MAHLI/MARDI because the amount of smear is vastly smaller with their interline sensors than for the frame transfer sensors of the engineering cameras.

From the MSL camera SIS http://pds-imaging.jpl.nasa.gov/data/msl/M..._SIS_latest.PDF :

In case anyone is still reading this fairly arcane discussion: per http://www.lpi.usra.edu/opag/jul2013/prese...o_efb_plans.pdf slide 24 there was no DSN tracking from 2.25 hours before to 1.5 hours after periapsis (as I should have realized, considering no DSN stations in view) and while ESA was tracking during most of that gap, I don't know if the ESA tracking data ever made it into the orbit determination.

I would still find errors of more than 5 km or so, at most, quite implausible.

Since most of the features in the mismatch area are clouds, I have wondered if this is uncorrected stereo parallax from the cloud height. But Gerald's match seems good enough that I wonder about that explanation; I haven't tried to work out the numbers. The altitude in this image was still about 3000 km.

As a rough check on the possible level of error in the spacecraft position, I compared the predicted position at the start time of EFB12 between spk_pre_130502_131130_130924_jc030.bsp (the last predict file before EFB) and spk_rec_131005_131014_131101.bsp (the reconstructed trajectory of EFB as known on 1 Nov 2013.) The delta position was 1.3 km, and that fits my recollection -- I was hoping that the mismatch artifacts would improve once we had the reconstruction, but they didn't.

What I don't know is how well the spacecraft was being tracked during EFB. The main observable is range and range rate as derived from precisely measuring the round-trip time between the DSN station and the spacecraft (see http://descanso.jpl.nasa.gov/monograph/ser...scanso1_C03.pdf ) but recall that Juno went into safe mode shortly after periapsis during EFB, and that would almost certainly have disrupted the tracking.

All that said, I'd still be very surprised by errors as large as what you are seeing, unless there is some out-and-out bug in the SPICE file production process.

As to those other error sources, I am certainly not claiming infallibility, but all of those have always been accounted for by our processing. The effective exposure time offset is certainly present, but my best estimate of that offset is about 81.88 milliseconds -- which doesn't explain the mismatch.
(Note that the velocity at EFB12 was about 14 km/sec so a 0.1 second time error translates to a position error of something like 1.4 km.)