Juno PDS data Options

[mcaplinger]

Regarding C kernels, I always use orientation data from the C kernel for every R/G/B set of framelets (typically 25-40 sets per image) and I also do this for the spacecraft position.

This is the only method I would have imagined would be adequate without a lot of manual tweaking, and it's the way the MSSS processing works. As far as I can tell from reading Brian's Mathematica code (I don't have Mathematica and the raw ASCII is not the easiest thing to read) he isn't using the C kernel data and he only uses the spacecraft position at the beginning of imaging, but his results are very good so perhaps this doesn't matter in most cases.

As for the expected errors, using our parameters the position error of the galilean satellites on orbit 1 had standard deviations of about 1 in X and about 2.8 in Y. I attribute the higher Y error to timing slop, but we could have residual geometric distortion error because the satellites were probably near the optic axis where distortions are lower. For obscure reasons, our own standard processing isn't using our updated parameters yet, though.

[Brian Swift]

.. As far as I can tell from reading Brian's Mathematica code (I don't have Mathematica and the raw ASCII is not the easiest thing to read)

Ewww (that stuff isn't pretty). If you download and install the much too large CDF Player you'll be able to view the document properly formatted.
(Hover over the right side to show section expansion controls.)

he isn't using the C kernel data and he only uses the spacecraft position at the beginning of imaging, but his results are very good so perhaps this doesn't matter in most cases.

My simple pipeline doesn't do map projection, so it doesn't use position. The only thing it uses from SPICE is Angular Velocity Magnitude for the spin rate.

[Gerald]

For my drafts, like these for PJ09, I don't use SPICE data, except data similar to those in the ik. It's a fixed processing pipeline that just uses the PJ number as a PJ specific parameter in order to know which directory to process. The other parameters are so similar between perijoves, that only higher quality requirements need a specific calibration.
The principle is similar to Brian's. Calibration runs are optional and based merely on distant Jupiter images.
This simplified processing method ends, where data about solar illumination, other 3D data, or accurate alignment of close-up features is required. Then SPICE trajectory and pointing data simplify processing considerably. For New Horizons, I made some experiments with infering orbital trajectory data, and mass estimates of Pluto and Charon from images. But that's rather complicated, time consuming, and not necessarily very accurate. Especially Jupiter with its oblate shape would add another challenge.

That said, Brian accomplished an important milestone in understanding JunoCam's way to take images.
This understanding is a value for itself, since it prepares you for the next level of challenges. And beyond some point, when you'll explore unknown territory, nobody will be able to give you useful help anymore, and you'll need to rely on your own acquired capabilities.

[Brian Swift]

Mike, Can you release to public domain the photo of the sensor and filters that is Figure 12 in "Junocam: Juno’s Outreach Camera"?
If not, I'll remove the copy embedded in the comments of my pipeline in the next release.

[mcaplinger]

Mike, Can you release to public domain the photo of the sensor and filters that is Figure 12 in "Junocam: Juno’s Outreach Camera"?

The paper is open access: "This article is distributed under the terms of the Creative Commons Attribution License
which permits any use, distribution, and reproduction in any medium, provided the original author(s) and the
source are credited."

[Brian Swift]

The paper is open access...

Thanks Mike. Can you make an original resolution version of the image available.

Also, do you know how accurate the .001s adjusted INTERFRAME_DELAY is?
I've only seen the values of the INTERFRAME_DELAY and adjustment given
to 1ms of precision, but I believe the accuracy is significantly better than that.

[mcaplinger]

Thanks Mike. Can you make an original resolution version of the image available.

I guess, but it's just eye candy without practical benefit, right?

Also, do you know how accurate the .001s adjusted INTERFRAME_DELAY is?
I've only seen the values of the INTERFRAME_DELAY and adjustment given
to 1ms of precision, but I believe the accuracy is significantly better than that.

If I understand your question, it's not. The delay is commanded in multiples of 20000 cycles of a 20 MHz clock, and the 1 msec offset was caused by an off-by-one misunderstanding in the commanding of the counter. So to the accuracy of the clock oscillator, which we don't know anything about other than it's within 20 ppm or so, the adjustment really is 1.0000 msec. It's probably slightly different, but we have no internal way of assessing that.

[Brian Swift]

I guess, but it's just eye candy without practical benefit, right?

I'm thinking of creating a diagram out of it by correcting the perspective and overlaying the filter readout ranges.

If I understand your question, it's not. The delay is commanded in multiples of 20000 cycles of a 20 MHz clock, and the 1 msec offset was caused by an off-by-one misunderstanding in the commanding of the counter. So to the accuracy of the clock oscillator, which we don't know anything about other than it's within 20 ppm or so, the adjustment really is 1.0000 msec. It's probably slightly different, but we have no internal way of assessing that.

The above is exactly what I was curious about. My modeling is currently estimating a value of 0.001032 sec for the adjustment.

[mcaplinger]

My modeling is currently estimating a value of 0.001032 sec for the adjustment.

Well, I can't say that's impossible, but it's about 30x larger than the largest clock error I would expect given the specification of the clock oscillator.

An error in interframe delay and/or spin rate would lead to increasing downspin errors over the course of a full image acquisition. Our star and galilean satellite imaging analyses don't show those to my eye (if I'm doing the math right the error you state would build up to 82*0.000032*371 or almost a second of error over a full spin, which would be easily noticable) but I don't claim to know for sure.

[Gerald]

82 * 32µs = 2.624ms. This would be a little less than 1 pixel. You won't probably be much more accurate on the basis of stars when working with a single swath.
But a relative error of 32µs / 371ms = 8.6e-5 would add up to about 1 sec within a little more than three hours. The clock is certainly more accurate by orders of magnitude.
So, the error is much more likely in the geometrical camera calibration than in the clock.

[Bjorn Jonsson]

The START_TIME value is also not accurate and this can be of significance. From the juno_junocam_v02.ti kernel:

We have found that there is a fixed bias of 61.88 msec in the start time with a possible jitter of order 20 msec relative to the reported value...

[Brian Swift]

Juno28g, a JunoCam raw processing pipeline implemented in Mathematica has been updated. It is available under permissive open source license at https://github.com/BrianSwift/JunoCam

Changes:

• Updates camera model to correct a “cross-spin flip”. This means tuning the rotation and tilt parameters is no longer needed (as long as Juno spin axis maintains its non-torquing orientation).
• Produces outputs with a 30 pixels per degree spacing calibrated in the along-spin direction. Cross spin spacing has not been calibrated, but is probably close to 30 pixels per degree.
• Supports scaling to 15, 60, and 90 pixels per degree. (Though excess memory use may lead to a crash if scaling up large (full-spin) data takes.)

[Sean]

Here is my first pass using Brian's updated pipeline. I can confirm memory burps when upscaling.

PJ12_100

[Brian Swift]

Here is my first pass using Brian's updated pipeline. I can confirm memory burps when upscaling.

Bit of a hack workaround for memory issues is to process a subset of frames with the frameRangeToProcess parameter,
which is what I used for processing the Io full spin images at 90 pix/deg.

[Brian Swift]

Juno24u, a JunoCam camera modeling Mathematica notebook, is available under permissive open source license at https://github.com/BrianSwift/JunoCam

This notebook produces the lens parameters used in the Juno28g raw processing pipeline.

From 29 CruisePhase and Oribit_00 data takes, 519 point source correspondences are automatically identified.

Modeling optimizes lens parameter to minimize mean of distances between paired points forward-transformed to equirectangular coordinates.

Various plots of residuals are produced to help evaluate the model and attempt to identify systematic modeling deficiencies.

This is a plot residual distances (in pixels) between pairs of forward-transformed points



These two plots show residuals in the Along-Spin and Cross-Spin directions.





The notebook contains many more plots (with tooltips for each point). These are viewable when the notebook is opened with Wolfram CDF Player available from https://www.wolfram.com/cdf-player/

A CSV table of point correspondences is produced for anyone else building a JunoCam camera model. This table is also available at https://github.com/BrianSwift/JunoCam

Additionally, PDFs annotating raw files are produced in which point sources used in modeling are circled and neighboring values of flattened and raw data are displayed.

A rasterized greyscale version of an annotated raw calibration file is available at https://www.missionjuno.swri.edu/junocam/processing?id=4468

When this data is input to a JunoCam raw processing pipeline, the resulting image can help evaluate how well the pipeline's lens/camera model aligns Red, Green, and Blue framelets.

The output produced by the current Juno24g pipeline is available at https://www.missionjuno.swri.edu/junocam/processing?id=4469