Juno development, launch, and cruise, Including Earth flyby imaging Oct 9 2013 Options

[Gerald]

... I've always assumed that the reconstructed SPICE trajectory would be extremely accurate in the Earth frame ...

Since the parameters interdepend, and before doing the more general theory, I'm going to try another manual approach, which assumes the SPICE trajectory being correct, and plays with camera parameters.
The actual optical axis might be displaced from the nominal value, and according to SPICE, it appears, that the camera is rotated 0.69° around z.
Geometric processing of the images would be considerably easier, if photometric determination of the trajectory wouldn't become necessary; so it's worth a try.

[mcaplinger]

Since the parameters interdepend, and before doing the more general theory, I'm going to try another manual approach, which assumes the SPICE trajectory being correct, and plays with camera parameters.
The actual optical axis might be displaced from the nominal value, and according to SPICE, it appears, that the camera is rotated 0.69° around z.

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.

[Gerald]

That's true, the discrepancy is more than 100 km (edit: I think, it's SPICE data to be adjusted about 400 km, mainly to the north). And the pointing of the velocity vector appears to differ.
But my analysis is yet too superficial to rule out cumulated effects by Earth's oblateness, some inaccuracy of the optical axis, light travel time, and some delay between nominal image time and effective exposure time.
A rigorous approach would be some rms minimization of a system of equations containing all potentially relevant factors. But getting this flawless always takes some time. The error functions sometimes have "valleys" allowing for common variation in several parameters without big effects on the error.
So I'm in some dilemma between causing unnecessary trouble for the deliverers of the SPICE data, and taking the risk, that some planning-relevant glitch might have escaped notice.
Since your rendition, too, shows some mismatch in the overlap region, this might be a hint towards inaccuracies in the trajectory data. But it's also possible, that we both have inaccuracies in the software or in camera parameters.

[mcaplinger]

That's true, the discrepancy is more than 100 km (edit: I think, it's SPICE data to be adjusted about 400 km, mainly to the north)...
But my analysis is yet too superficial to rule out cumulated effects by Earth's oblateness, some inaccuracy of the optical axis, light travel time, and some delay between nominal image time and effective exposure time.

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.)

[Gerald]

In the meanwhile I've tried several time offsets along the trajectory, and can now almost rule out the possibility, that the mismatch can be healed that way. The distance to Earth is changing rapidly. The necessary adjustment of the camera FOV results in other mismatches.
To adjust for the north-south displacement, I needed to shift time about 8 seconds, with an obvious error in the distance, and unlikely large displacements of the camera optical axis.
So, I'm inclined to agree, that a rather displaced (SPICE) trajectory seems to be the best explanation sofar.
Although from a flight-dynamical point of view, the flyby must have been very accurate.
In any case, I think, I'll try to get the photogrammetric approach running.

[mcaplinger]

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.

[Gerald]

This image is a crop of the not yet fully optimized efb12 image, a few posts above:

It's supersampled about 4x the raw image.
If you look closely, you'll see the shadows of several clouds, a few pixels right of the respective cloud.
Since it's possible to register the clouds, their shadows, as well as the coastline, with a common displacement - at least almost - the parallax and the motion of the clouds can explain only small mismatches.

Back-of-an-envelope calculation:
Assume a cloud height of 20 km at a distance of 3000 km. The maximum apparent distance in pixels would be about
1600 pixels x arctan(20km/3000km)/58° = 10.5 pixels.
The parallax needs to be much less. Say the spacecraft moves 30s x 14 km/s = 420 km. As an order of magnitude estimate, we get
10.5 pixels * 420 km / 3000 km = 1.5 pixels
as an upper bound for the parallax.

[Gerald]

Assuming the SPICE trajectory as correct, adding a time delay of 205 ms, allowing for (preliminary) nutation/precession of about 7e-5 radians per exposure, and placing the optical axis to (790;600) allowed for a fairly good result. Here a crop:

[Bjorn Jonsson]

When I was dealing with the Juno data following the Earth flyby by far the biggest source of errors was the interframe delay. According to the LBL file associated with the image I was using it was 0.370 but 0.371 worked considerably better. It is probably possible to get even better results by fine tuning the 0.371 value. Distortion due to optics was also an issue and I was correcting for this using the K1 Brown correction factor but I'm not entirely confident I was doing it correctly. I was always planning on revisting these issues well before JOI and now all of a sudden JOI is less than two months from now. Yikes!

Interestingly, I also notice that there are still many 'ancient' instrument kernel files at the PDS NAIF site.

[Gerald]

When you go down to the pixels, there are so many parameters which might play a role.
There is maybe a Brownian K2. But playing with the Brownian parameters didn't show much effect regarding RGB registering.

I've been working with subframes as a unit of time, as an alternative to time in seconds. So the interframe delay in absolute terms cancels out.
But now I'm returning again to seconds as the unit of time in order to simplify usage of SPICE position data.

To overcome the inconvenient assumption of precession/nutation, I've reduced the rotation period of Juno to somewhere between 28 and 28.5s for EFB12, instead of 30s. Another parameter to play with is Earth's radius due to the uncertain mean land/cloud height above sea level.
But there are still inconsistencies I don't yet fully understand. They get the more obvious the farther one extrapolates from the position the images have been taken.

...With each accomplishment there come new ideas, what one could do with the images.
Currently I'm trying to find a way to register RGB with methane images, since false color images including methane images are one of the suggested types of high-level products.

Edit: Saying this, I just understood, that one of my attempts is impossible to solve: Accurate RGB registering of Earth's limb in the overlap region.
Due to the change of perspective, the channels cover a different surface area: One color channel is seeing part of Earth's surface which is behind the horizon for another color channel, 30 seconds later.

[Gerald]

EFB11 and EFB12 reprojected for the same instant 2013-10-09T19:12:30.000


EFB11 is a "methane" image.

[Gerald]

As a proof of principle, here a false color image combined from the reprojected EFB11 and EFB12 images of the previous post:

In the combined image, the green channel of EFB 12 is replaced by the "methane" (near infrared of about 890 nm) channel EFB 11, followed by some color enhancement.
Since the chlorophyll of plants reflects sunlight in the near infrared, the continents look greenish in the false-color image.

The image contains camera artifacts from interline-smear, since JunoCam has been designed for Jupiter, a much less illuminated target.
Better registering of EFB11 and EFB12 is work in progress.
Note also, that the perspective changed between EFB11 and EFB12, and so did the specular highlight on Earth. This shift of the reflection isn't adjusted in the image.

[Gerald]

In order to prepare for Jupiter approach imaging, and as a tiny step towards reproducibility and standardization, I've reviewed EFB01 (RGB image of our moon) :
Here a crop:

And a file remotely similar to a PDS LBL, with some metadata of the original processing:
 JNCR_2013282_00C091_V01_out_240_81.081_1468.0_0.0_617.0_0.740_0.880.LBL ( 1.15K ) Number of downloads: 162

(Syntax and identifier conventions aren't quite compliant with PDS3, but hopefully better than no metadata. There may also exist some requirements for LBLs I'm not (yet) aware of.)

[Gerald]

Despite several issues, I thought I should keep you roughly up to date with the advancements of the efb image processing.
This animation is a 250-fold time-lapse derived from the preliminary PDS versions of efb04 to efb13. So the blocking issue is inherited from those files; don't look too close. But you get a feeling about the rythm, with which the efb images have been taken; the animation switches between underlying swathes close to the start times of the respective swathes. I've a yet unfixed glitch in the consideration of the offset of Earth's rotation for an individual swath; so I needed to set this parameter to zero, resulting in a small jump of Earth's rotational state when switching between the individual swathes within the animation.
The sampled resolution is 3 pixels per degree, hence about a 10th of the camera resolution.
The space background of Earth is cropped in this animation. I'm working on a solution to add it again.

The other message is: I'm very close to finding a solution which is consistent with the SPICE trajectory.
 efb_anim10_0.2050_3px000000_30.2420_81.484_0.avi ( 862.04K ) Number of downloads: 243


I've determined the camera parameters of the animation manually, except the trajectory (from SPICE) and times (from raw image metadata), e.g. by applying interval bisection.
I've assumed 81.484 subframes per Juno revolution, and 30.242 seconds per revolution, hence 371.14 ms interframe delay.
Those values should be rather accurate down to possibly a small error in the respective least significant digit, unless I've a yet undetected systematic error in the rendering software.
I've assumed a spherical Earth with radius 6385.0 km, and a pinhole scale factor of 1486.0 pixels per x/z. These two values may be less accurate, with possible inaccuracies of a few per mille. I've left the Brownian K1 unchanged with respect to the preliminary laboratory value.
Here more detailed LBL-ish files with more or less cryptic program parameters:
 efb_anim10_0.2050_3px000000_30.2420_81.484_0_LBL.zip ( 9.91K ) Number of downloads: 181


I'm considering to implement an RMS method to narrow further down the camera parameters, but that's work for several weeks. First, I'll run a few tests, to see whether I'm already below 1 pixel rgb mismatch; this would be sufficient for "pretty pictures", but not yet quite for precision measurements or superresolved products.

[Gerald]

EFB11 and EFB12 have been taken while Juno was approaching Earth. So these two images aren't perfect for stereo vision.
And to make it even more challenging for you ( no it's the only reprojection method I've readily available ), I've reprojected the two images to cylindrical/spherical virtual camera coordinates. Hence, if you're experienced in x-eyed vision, and ready to risk some headache, you may try to see the following pair of images as one 3d image:

(Image credits: NASA/JPL/SwRI/MSSS/"Gerald"@UMSF)

Parameters are the same as for two selected images of the above animation, except for the sampling rate being 15 pixels per degree.

Stereo pairs will work better near periapsis, so we can look forward to the experiments the JunoCam team is preparing for perijove.