Ganymede Flyby - PJ34, June 7, 2021 Options

[Bjorn Jonsson]

Interesting, I thought it was possible to post more file types than images provided they are not executables, ZIP files or similar. But I managed to convert the transfer format file using the tip posted above.

[volcanopele]

So here is 34C00001 using Brian's SPK file and my control network:



Definitely improves the limb fit and the color fringing that's easiest to see near the terminator is much reduced, though there are a few area where it is more noticeable. I didn't change the start time for this observation. I just took the framelets that already have some processing done to them, used spiceinit to change the SPK file, then ran jigsaw again using my control network. Then I map projected each framelet and mosaicked again. Still not perfect, not sure if that's due to the camera model or some remaining spacecraft offset issues.

EDIT: looking carefully, I'm not sure this is true... honestly, it doesn't look like the pointing really improved all that much except for the limb fit now being spot on.

Not entirely happy with doing it this way. I thank Brian for the edited SPK file, that certainly works. But I am still hopeful that ISIS 6 (now a release candidate) will solve the issue with jigsaw with updating spacecraft position. A big reason for going through this exercise was to craft a processing plan/script for the later Io encounters by using Ganymede as a test case (Ganymede better get used to that position, it'll be used in much the same way later in the early 2030s). so I will come back to this once ISIS6 is released in a few weeks.

On a side note, while the Ganymede map produced by the JANUS team is fantastic, and very detailed, I am not getting good results using it with my control network. Mid- to high-northern latitudes are a particular concern. Could be my fault. Maybe there is something wrong with the mapping labels I applied, but I don't think so. I pulled those numbers from the geotiff. So I reverted to using the USGS map. I don't have the time to attempt to fix the issue if it is my fault.

EDIT: Jason is having way too much fun with control point networks:

[Brian Swift]

So here is 34C00001 using Brian's SPK file and my control network:
...
EDIT: looking carefully, I'm not sure this is true... honestly, it doesn't look like the pointing really improved all that much except for the limb fit now being spot on.

Your comments caused me to go take another look at my timing parameters. I see the PJ34_01 timing offset is not "good". I hadn't noticed that it is stuck up against the edge of the range my optimization uses for timing offsets. Will rerun with a larger range, but a timing offset this large is an indication to me there could be some other problem.

...
EDIT: Jason is having way too much fun with control point networks:

Yup, fun with control networks.
https://vimeo.com/581719195

[JRehling]

It sounds like this is not the issue for this flyby, but what is the resolution of a control point? It certainly has to have some limit, and when it's topographical, like the central peak of a crater, it will shift depending upon different illumination. What makes that thorny is that many such points will shift systematically under different illumination conditions. (That will not happen with albedo features on a flat body, like if someone conveniently painted crosshairs all over a world.) On a world like Europa, the situation may approximate the latter, but with a world where albedo variations are muted and topographical features predominate, the second order effects are going to be the limiting factor on resolution, until/unless topography is accounted for.

[mcaplinger]

It sounds like this is not the issue for this flyby, but what is the resolution of a control point?

https://ntrs.nasa.gov/citations/19880057291

Unfortunately if there's an online version I don't know where.

[Brian Swift]

...It certainly has to have some limit, and when it's topographical, like the central peak of a crater, it will shift depending upon different illumination. What makes that thorny is that many such points will shift systematically under different illumination conditions. ...

The abstract of this (paywalled) 2016 article states the authors have techniques of addressing different illumination conditions.
A technique for processing of planetary images with heterogeneous characteristics for estimating geodetic parameters of celestial bodies with the example of Ganymede

[volcanopele]

For these observations, it doesn't really matter that much because the lighting conditions don't change all that much between the two observations I used, but it was enough that I did have to do some matches by sight (using the blink feature in qnet) between 34C00001 and 2. For some of the fixed points, I used a few points that matched up albedo features rather than topographic features and again didn't rely in autoreg for co-registration.

[JRehling]

JIRAM results for Ganymede (both flybys) look promising; I'm sure that analysis will be forthcoming.

https://www.nasa.gov/feature/jpl/nasa-s-jun...f-moon-ganymede

[volcanopele]

The bug I've mentioned in jigsaw in ISIS is now fixed in the version out today (5.0.2). Just tested it out and I have to say, it looks spectacular:

[Brian Swift]

The bug I've mentioned in jigsaw in ISIS is now fixed in the version out today (5.0.2). Just tested it out and I have to say, it looks spectacular:

That looks great. Did you use my SPK or the default? And does ISIS report its optimized spacecraft position, attitude, or image timing offset?
I'm curious to compare with what I'm coming up with.

[volcanopele]

I used juno_sc_rec_210606_210612_v01.bc and juno_rec_210513_210630_210707.bsp for a priori pointing and position, not your kernel.

I've put the trajectory and pointing kernels that ckwriter and spkwriter output in a Dropbox folder:

https://www.dropbox.com/sh/p7dsul2eyocjp3u/...tSP0Us_0la?dl=0

Note that these kernels only cover the first two Ganymede observations. I also made no adjustments to the start time of either observation.

EDIT: I threw in some of the files that jigsaw output as well as that might help with seeing the offsets I measured. note that offsets are WRT Ganymede.

[Brian Swift]

...
Note that these kernels only cover the first two Ganymede observations. I also made no adjustments to the start time of either observation.

Yup, no need for a start time offset since your configuration is solving for camera pointing angles.

EDIT: I threw in some of the files that jigsaw output as well as that might help with seeing the offsets I measured. note that offsets are WRT Ganymede.

Thanks, good stuff. I must say, the 12 second optimization looks pretty tempting, compared to my .5 to 2.5 hour optimization runs.

[MarcF]

To come back to JIRAM data represented at:
https://www.jpl.nasa.gov/images/ganymede-co...ent-aboard-juno
The coverage shown is from the 2 distant flybys. I expect spectacular pics from the close flyby, with an amazing resolution (localized at the overlapping part). I think we will have to wait analysis and publication of data to see them.
I'm also confused by the picture published in the link. The background map in inverted and the surface structures actually covered by JIRAM are not those shown in the pic. I'm quite amazed that such a mistake could have been made.
Best regards,
Marc.

[Brian Swift]

Corresponding Points Search Visualization https://vimeo.com/586883448

[JRehling]

I'm also confused by the picture published in the link. The background map in inverted and the surface structures actually covered by JIRAM are not those shown in the pic. I'm quite amazed that such a mistake could have been made.

Did you notice that the "first" flyby in this work is not the first flyby from 2021, but a previous flyby from Dec. 26, 2019? Then, the "second" flyby in this work is from July 20, 2021. The June 7, 2021 flyby is not represented.