[X] My Assistant

[elakdawalla]

There is now PDS-format JunoCam cruise and Earth flyby data available; it's been submitted to the PDS, but MSSS has gone ahead and posted it on their website. I've created an index page to it here. Unlike my usual index pages, there aren't any thumbnails because of the odd nature of JunoCam images, with their long skinny shapes and interleaved framelets. I haven't played much with these data because it's a bit beyond my skill -- I look forward to seeing what any of you can do with it.

[Bjorn Jonsson]

The new frame and instrument kernels (plus information/comments they contain) mentioned in the previous post have eliminated most of the systematic errors I have been getting, meaning that the corrections I need to make to the camera pointing are now much smaller. What I'm doing is comparable to what ISIS3's deltack does. However, small errors apparently remain. Because of this there is one issue I hope Mike can clarify (I suspect Gerald also knows something about this).

juno_junocam_v02.ti has lines like this:

INS-6150#_DISTORTION_X = 814.21

The width of the images is 1648 pixels. Does the above line mean that the optical axis passes through x=814.21 in the images and not width/2 (=824) as in other spacecraft cameras (e.g. Cassini, Voyager, Galileo and Dawn) I'm familiar with?

[mcaplinger]

Does the above line mean that the optical axis passes through x=814.21 in the images and not width/2 (=824) as in other spacecraft cameras (e.g. Cassini, Voyager, Galileo and Dawn) I'm familiar with?

Yes. At least that's what we are suggesting you use in the camera model. No camera really has the optic axis going directly through width/2 -- if it says it does, that most likely only means that other parts of the camera model have been adjusted to compensate for that assumption (camera model parameters don't have to be physically accurate as long as the residual errors are low.)

For this most recent kernel update, we (a summer intern and I) measured thousands of cruise star image locations and then used Nelder-Mead nonlinear optimization to minimize camera model error while varying seven model parameters: image optical center (cx, cy), the first two terms in the radial distortion function (k1, k2), camera focal length (fl), and camera boresight angular misalignment in X and Y (xr, yr). The residual error is still about 1 pixel cross-spin and ~2.5 pixels down-spin (1 sigma); the latter higher because of remaining timing slop.

[Brian Swift]

For this most recent kernel update, we (a summer intern and I) measured thousands of cruise star image locations and then used Nelder-Mead nonlinear optimization to minimize camera model error while varying seven model parameters: image optical center (cx, cy), the first two terms in the radial distortion function (k1, k2), camera focal length (fl), and camera boresight angular misalignment in X and Y (xr, yr). The residual error is still about 1 pixel cross-spin and ~2.5 pixels down-spin (1 sigma); the latter higher because of remaining timing slop.

Hi Mike,

I’ve also been looking at PDS cruise phase full-rotation color images for camera geometry calibration. I noticed what appear to be changes in compression artifacts between datatakes without an indication of a change in the .LBL file. For example, between JNCE_2016026_00C00063_V01 and JNCE_2016026_00C00064_V01.
Could you comment on that?

I also wonder if there are opportunities for non-standard imaging around apojove (or any time Jupiter is fairly small in the FOV). If so, some imagery I think could be useful are:

1. Command JunoCam to disable TDI and capture a full rotation of color frames with EXPOSURE_DURATION around 464ms to 816ms. The goal being to capture bright stars or moons as slightly curved trails passing over filter boundaries, which could then be used to help characterize chromatic aberration and geometry. Ideally, collect several of these at different altitudes to capture trails from the moons in different sets of CCD columns.

2. Collect a sequence of low compression color frames spanning more than one full rotation. The goal being to allow wrap around linkage for FOV measurement to be performed with more stars (and away from the first frame which seems to have a higher noise level). Ideally, collect a series of these, each starting at a different random rotation angle.

Thanks,
Brian Swift

[mcaplinger]

I noticed what appear to be changes in compression artifacts between datatakes without an indication of a change in the .LBL file. For example, between JNCE_2016026_00C00063_V01 and JNCE_2016026_00C00064_V01.
Could you comment on that?

A visual example of what you are reacting to would be helpful.

Without looking at these specific images, we've observed an effect where as the sensor warms up during operation, the dark level in the images interacts with the companding table in such a way as to (paradoxically) make the images less noisy, which changes the behavior of the lossy compressor. Unfortunately, the PDS archive product wasn't defined with a field to record what the actual compression factor was (that is, we don't record how big the original downlink file was), which would give some indication of what level of compression artifact to expect.

I also wonder if there are opportunities for non-standard imaging around apojove

At the moment Junocam is turned off except near perijove, and the time near perijove is fully subscribed with images of the planet.

With regard to calibration, my philosophy is to try to extract all the information possible from images that we already have before taking new images. There were a few instances in cruise where the TDI was commanded assuming the spacecraft was spinning at 1 RPM and it was really spinning at 2 RPM, and these images have the kinds of streaks you're describing. We just ignored them when we were doing our calibration, but maybe they have some utility.

There are many, many images taken all the way around the orbit on orbit 1 of the moons with no TDI, and that's a good source of geometric information that we are in the early stages of looking at.

Taking long exposures without TDI is outside the parameters that the instrument was designed to work within. It might be possible to command this, but obviously you can't take contiguous frames around a spin so you'd be taking images of somewhat random star fields.

[Brian Swift]

A visual example of what you are reacting to would be helpful.

As an example, the below images are the third frames from JNCE_2016026_00C00063_V01.IMG and JNCE_2016026_00C00064_V01.IMG which have START_TIMEs 2016-01-26T08:56:02.168 and 2016-01-26T09:01:02.082. The images were decompanded and DN 0 to 8 were stretched full display range.

Unfortunately, the PDS archive product wasn't defined with a field to record what the actual compression factor was

Besides compression factor, are there other instrument configuration parameters that effect imaging characteristics which are not recorded in the metadata?

At the moment Junocam is turned off except near perijove, and the time near perijove is fully subscribed with images of the planet.

OK. If I decide to request some special imaging I’ll run it though the perijove voting process, with the imaging to occur during or at the end of the departure movie collection.

There are many, many images taken all the way around the orbit on orbit 1 of the moons with no TDI...

Great, I’ll go look for them on PDS. I’d assumed all the non-cruise imagery was on the missionjuno web site.

One more question: is the imagery collected for the Junocam Calibration Report available online anywhere?

Thanks again.

[mcaplinger]

As an example, the below images are the third frames from JNCE_2016026_00C00063_V01.IMG and JNCE_2016026_00C00064_V01.IMG

Yes, that's an example of the effect I described.

Besides compression factor, are there other instrument configuration parameters that effect imaging characteristics which are not recorded in the metadata?

If we ever changed any of the piecewise linear companding parameters (which we don't plan to do) there is no place to record them in the metadata. One issue is that the PDS doesn't easily provide a way to define new keywords and has a pretty sparse set of standard keywords (for example, we had to lobby to get a keyword to describe the amount of TDI -- even though TDI has been used on earlier instruments, there is no standard keyword for it.)

One more question: is the imagery collected for the Junocam Calibration Report available online anywhere?

Not publicly, no, not at this time. Some missions archive their ground data and some don't, and of the ones that do, some of them spend a lot of effort to make that intelligible and some don't. Most of our ground images were taken with ground support equipment that read out a large area of the CCD including the "junk" between band edges, and so it doesn't fit perfectly into the definition of the standard PDS product.

If I thought any of the ground images were generally useful, I'd be more interested in trying to get them into some releasable form.