Juno PDS data Options

[Gerald]

For DCT compressed images, you get the usual type of compression artifacts, of course.

Here is some selected calibration run for PJ09 images, I think, it's #001 to #041 RGB approach images:

The top right diagram shows the inferred rotation around the optical axis in radians under constant assumptions for Brownian K1, K2, and for a fixed z/x scale factor.
You'll see, that this is fluctuating between -0.1 and +0.1 degrees (between -0.002 and +0.002 radians).
This calibration run used a 7-parameters camera model with 3 assumed and 4 inferred parameters.
I've also tested several model extensions with more parameters, but I've no final opinion, yet. There are many ways to get almost-aligned images. I haven't yet had the time to implement a more global RMS error minimization method applied to a more complex camera model and to many images at the same time.
As long as I don't need to work scientifically very accurately, the model assumptions I'm currently applying return useful images. So, the pressure to squeeze out another digit of relative accuracy isn't very high at the moment.
But there are some other tasks until mid March that can't wait. I see some hope to be able to continue with more complex calibration runs in the second half of March, before PJ12.

[mcaplinger]

So, I was curious how much the spin axis has changed

The spacecraft sends down its orientation as determined by the star trackers at fairly high resolution and these data are assembled into the C kernels, so it's not like this is some big mystery if you are using SPICE.

I’ve wondered about is the effect of onboard compression...

Certainly there is a small effect, especially for the high compression factors we were using for star imaging in cruise. But I wouldn't say it's any more significant than other sources of error, like motion blur from spacecraft nutation. We didn't even bother to compute centroids for our analysis, we just used the eyeball location of stars. As I've said before, expecting subpixel registration without any manual adjustment steps is probably not achievable.

[Brian Swift]

This calibration run used a 7-parameters camera model with 3 assumed and 4 inferred parameters.

Does this mean all your inferred (extrinsic) parameters are only derived from the imagery and don't rely on SPICE geometry?

[Gerald]

Inferred means inferred from raw JunoCam images.
Assumptions can be from any source, including SPICE, or just guessed, or arbitrary.

[Brian Swift]

Note for anyone else who hasn't noticed...
The coverage dates of SPICE kernels at http://wgc.jpl.nasa.gov:8080/webgeocalc/#FrameTransformation
which currently only go through 5/2017 (PJ6) when "JUNO" kernel set is selected can
be extended for PJ7-PJ11 by:
1. Initially select JUNO
2. Select "Manual" (at the bottom of the pulldown) "Choose Kernels..."
3. Navigate to "JUNO/kernels/ck"
4. Select the "juno_sc_rec_yymmdd_yymmdd_v01.bc" with a date range covering the desired time.

[mcaplinger]

Inferred means inferred from raw JunoCam images.
Assumptions can be from any source, including SPICE, or just guessed, or arbitrary.

I'm not sure that answers the original question.

To the extent that I understand Gerald's processing flow, he uses the spacecraft position data (SPK file) at least in some cases, but never the orientation data (CK).

[Gerald]

I'm not quite sure any more, what we are talking about.
For the geometrical camera calibration, I don't need SPICE data, but can use them.
For processing close-up images, or for rendering illumination-adjusted images, I'm using sets of 8 dumped (saved) trajectory position files with different frame settings, that implicitely contain all relevant kernel informations including CK.
But the processing is considerably more complex than the processed images might suggest.

[mcaplinger]

For processing close-up images, or for rendering illumination-adjusted images, I'm using sets of 8 dumped (saved) trajectory position files with different frame settings, that implicitely contain all relevant kernel informations including CK.

I guess I assumed since you independently computed the spin rate and axis from the marble images that your position information was in an inertial or Jupiter-fixed frame and didn't include any knowledge of spacecraft orientation, but I guess if you have position in a spacecraft-fixed frame then the orientation is convolved into that.

That aside, I've tried to document the standard processing flow in the Junocam I kernel. There's some evidence that this works to 1-2 pixel accuracy, and I don't think one can expect anything better than that without doing limb fits or some kind of ad hoc color registration.

[Brian Swift]

Here is some selected calibration run for PJ09 images, I think, it's #001 to #041 RGB approach images:

From the drawing conclusions from a single data point department...

Left is first image of PJ09 approach showing a large glitch with my default rotation,
right is using .0025 rotation from your graph.

[Brian Swift]

Gerald, do you have a RotOffestZ estimate for JNCE_2017244_08C00121 easily accessible?
It's an image I use often in development and testing.

[Gerald]

The effect in your comparison is indeed larger than I remembered. For the small marble movie images, a misalignment of one or two pixels can be rather obvious.
For PJ08, I've performed calibration runs only for the early approach phase, but with several different sets of assumptions.
For the same assumptions used in the above PJ09 calibration run, the best-fit data have been around .002 radians rotation around JunoCam's optical axis.
But this might have convoluted unmodeled s/c or camera properties specific to the position of Jupiter in the early approach images.

During the first few hours after a s/c op, Juno may oscillate a bit, before it's dampened down to the level of statistical noise.

[mcaplinger]

During the first few hours after a s/c op, Juno may oscillate a bit...

True. If you're using the C kernel, any oscillation should be captured in the kernel. If you're not using the C kernel, then all bets are off. I still find it hard to tell in this whole exchange if people are using the C kernel, and if so, how and when.

If there are errors in the angular offsets for Junocam in the I kernel and frames kernel, or if there's spacecraft motion not being captured in the C kernel, I'd like to know about those problems so they can be fixed.

[Brian Swift]

The effect in your comparison is indeed larger than I remembered.

In my original PJ09 approach movie (with all frames processed using
the same orientation parameters), it was only this first frame that
had a large glitch. Since your graph showed it as an outlier, I was curious if
using your rotation value would correct it.

[Brian Swift]

I still find it hard to tell in this whole exchange if people are using the C kernel, and if so, how and when.

I currently only use the SPICE "AV Magnitude" as the spin rate in my image production pipeline.
(This pipeline is fairly basic, not doing image rectification.)

I use no SPICE info in my lens modeling process.

[Gerald]

... I still find it hard to tell in this whole exchange if people are using the C kernel, and if so, how and when...

In my usual way to process images, I'm using C kernel information only for a small number of selected trajectory positions, and extrapolate s/c and camera pointing on the basis of actual images.
With some effort, I could probably optionally replace my own pointing calculations by data retrieved from SPICE, or I could use more or redundant trajectory positions with C kernel information and extrapolate to overlapping trajectory fragments for consistency tests. But as of yet, the processing doesn't allow a fully conclusive error analysis of SPICE data. Easiest to check would be fluctuations of the rotational phase angle wrt actual images by using SPICE pointing information from very close to the time an image has been taken, e.g. SPICE data of image start or stop time (rounded to one or five seconds).
In general, for more recent perijoves, I needed less adjustments of the data retrieved from SPICE than I needed before. That may be partially due to more practice, but proably also due to improved quality of the data.