isis3 remaps images - there is no back to camera mapping (map2cam) for juno images

the Earth fly by image "JNCE_2013282_00C00102_V01"



--- edit ---

for some unknown reason the jpg's of the tiff images are not uploading
-- so on to imagebox
Simple cylindrical ( color is over saturated )

ortho( color is over saturated )

BlueMarble -- in the same ortho projection for comparison

Thanks for posting these, they answered my question.

The image below shows per-channel overlays of the limbs of Io and Jupiter as predicted by our best current model for PJ16-011, no timing adjustment other than our nominal recommended one. The Io limb is pretty close to dead on (maybe a pixel off in the red) and the Jupiter limb is clearly low relative to the observed limb by 4 pixels or so. So that does support the idea that what we see is higher than the limb defined by the IAU radii in the SPICE planetary constants file. Of course, the observed limb is not super-sharp so it's a judgement call about where it is exactly.

Juno data (including JunoCAM but excluding JIRAM) for PJ13 and PJ14 is now in the PDS:

https://pds.nasa.gov/datasearch/subscriptio...-20190211.shtml

I briefly considered fitting for the planet radius but decided not to for several reasons. The biggest reason is that I suspect the cloud altitudes vary depending on cloud 'type' (light or dark). In particular the bright, white ammonia clouds should usually be at a higher altitude than the darker clouds. In other words, if this correct Jupiter's shape is slightly 'irregular' if you define Jupiter's radius by the top of the visible clouds and not by a specific pressure level. I think I may have seen tentative evidence of variable cloud altitudes at the limb in some images but I'm not completely sure yet and need to look further into this. Another possible source of errors is that a reconstructed SPK kernel doesn't become available until several weeks after a a flyby. I have yet to compare the reconstructed SPK kernels to the predict kernels that become available immediately.


This is very interesting and I'll probably do some processing runs to see if I get similar results (I hadn't processed these exact images yet). I'm especially interested in the start time adjustment.


And also the cloud tops are probably not at the same pressure level everywhere - see above.


Big thanks for posting these, I've been wanting to see something like this for some time. Typically, the errors I'm getting at Jupiter's limb are similar to this when I adjust the start time using the recommended values but the fuzziness of the limb often complicates matters and makes it difficult to locate the cloud tops.

I believe there was a change of about 8ms on PJ16_11 (Scratched my head for bit trying to figure out why I wasn't getting the same result I had produced earlier, and eventually realized I'd update the SPK at some point).

FWIW, in my matching code I gradient filter the image and define the limb as the maximal gradient.

The start times could all easily be off by a constant since my model uses its own spacecraft to camera frame transform matrix. (I haven't checked to see how much z-rotation difference there is between mine and the standard matrix).

Update to Juno3D pushed to https://github.com/BrianSwift/JunoCam/tree/master/Juno3D

• Produces Python commands to automate Blender rendering configuration
• Updated bias/gain masks

Mike, I just noticed that prior to PJ10 TDI=1 was rare (TDI=2/3 typical), but from PJ10 forward TDI=1 seems to be the default.
I'm just curious, can you comment on the motivation for the change?

Higher signal levels due to the evolving sun angle.

We are still using high TDI for some of the polar images in an effort to see the circumpolar cyclones better.

Mike, can you describe the Map Projection used for images that accompany the raw data images on the missionjuno site,
or point me to and existing description.

It is an uncontrolled point perspective projection only intended as an unofficial pretty picture and not archived with PDS.

At long last I'm adding methane channel processing to my processing pipeline. I'm using image PJ25_19 for testing. My problem is that I am getting large geometric errors but then I remembered discussion of tests where the methane image readout region was changed. I strongly suspect this is the reason for the geometric errors and if I'm correct the IK kernel is incorrect when processing the PJ25 methane images. What is the location of the new readout region, either in absolute pixel coordinates or relative to the readout region before the change?

Has the new/changed readout region been in use after a specific date/perijove or is the 'old' readout region still used in some of the recent images?

For the new readout region, INS-61504_DISTORTION_Y should be 405.48 (the first line of the region changed from 291 to 201.)

Inconveniently, we continue to switch back and forth between the two readout regions (we have to use the old methane setting to take RGB data as it happens because the parameters depend on each other). Typically the old one is used on distant images and the new one only on images close to perijove. For PDS products this will be indicated in the comment for each image somehow, but I'm not sure if this information will show up in the missionjuno metadata.

Sorry for this confusing state of affairs, we didn't anticipate that we might want to change these parameters at all.

Mike, is the data for the "Junocam relative filter response" table on page 6 of the "Junocam Calibration Report" available anywhere?
Also, can you describe from what locations on the CCD the monochromator values were obtained (and/or share example images)?
(considering possible impact of flat field on measured filter response)

Has anyone worked with ISIS cubes produced with junocam2isis fullccd=yes?
Does it seem sensible that the produced cubes are single rather than 3-band?