Beginner level projection Options

[adamg]

Hi,

I'm trying to do the mapping just using SPICE for the Junocam images rather than going through ISIS. It might seem like I'm making life difficult for myself but I just wanted to make sure I'm doing the bare minimum amount of processing so it looks as close to a non-spinny-push-frame image as I can. I'm making all the beginner mistakes but I can't seem to figure out what they are so I was hoping someone might give me a hint?

First I want to figure out how far Jupiter is because I want to have anything that didn't hit Jupiter get mapped to a sphere that hits Jupiter. This means any lens effects can get mapped in space near where they originated from which should hopefully make the edges of the planet seem less processed:

[jupiterPos, jupiterLt] = spice.spkpos('JUPITER', et0, 'JUNO_SPACECRAFT', 'NONE', 'JUNO')
jupiterDistance = np.linalg.norm(jupiterPos)

Then I go through all the undistorted Junocam pixel vectors and figure Jupiter intercept points in the IAU_JUPITER frame so now I have a point cloud of all the planet mapped pixels:

[point, trgepc, srfvec, found ] = spice.sincpt(
'Ellipsoid', 'JUPITER', et,
'IAU_JUPITER', 'LT+S', 'JUNO_SPACECRAFT',
'JUNO_JUNOCAM', v)

If it didn't find an intersection then I figure out where that invisible sphere is going to be by extending out the pixel vector by the separation and move that to the IAU_JUPITER frame:

direction = np.array(v)
pos = direction*jupiterDistance/np.linalg.norm(direction)
rotationMatrix = spice.pxform('JUNO_JUNOCAM','IAU_JUPITER',et-jupiterLt)
pos = spice.mxv(rotationMatrix, pos)

It works terribly! I seem to have a timing error in the frame offsets that seems suspiciously close to the light time between Jupiter and Juno and the sphere that catches all the sincpt misses is completely miles off. I've been staring at the code for a while and not figuring my mistake, I was hoping someone might point out where I've gone wrong.

Many thanks


Adam

[Brian Swift]


Hi Adam, Welcome to/from the JunoCam raw processing community.

Mapping pixels that don’t intercept Jupiter to an “invisible” sphere is a cool idea, it’s what my processing pipeline does. ;-) I refer to this sphere as the backstop surface. As far as I know, none of the other JunoCam pipelines use this technique.

My pipeline is implemented as a Mathematica notebook available as Juno3D at https://github.com/BrianSwift/JunoCam/tree/master/Juno3D
While my software is permissively free, unfortunately Mathematica’s licensing costs create a significant barrier to its usability.

On your sincpt, double check that 'JUNO_SPACECRAFT',
'JUNO_JUNOCAM' are in the correct parameter position. My calling sequence is

CODE

  sincpt["Ellipsoid", targetName, frameTime, fixref, "CN+S", "JUNO", "JUNO_SPACECRAFT" , pixVecSC ]

but my bridge from Mathematica to the SPICE library may have a different calling sequence than python’s. (Note, don't try substituting "JUNO", for "JUNO_JUNOCAM". I don't use JUNO_JUNOCAM because my pipeline uses a different camera model than found in SPICE.)

With respect to projecting non-intercepting imagery onto a backstop sphere,
rather than moving a point intersecting the backstop sphere into the IAU_JUPITER frame
I define my backstop sphere in the IAU_JUPITER frame and then just compute where the pixel vector intercepts the backstop.

Also, my backstop sphere radius is set to intersect just inside the limb rather than at Jupiter's core to avoid a camera distance discontinuity between intercepting and non-intercepting imagery.

Also note Jupiter’s visible limb can be at a higher altitude (by tens of km) than the SPICE 1-bar limb. This is noticeable with imagery collected near perijove.

Finally, you’ll find a lot of processing discussion under the “Juno PDS data” topic at http://www.unmannedspaceflight.com/index.php?showtopic=8143

[mcaplinger]

Mapping pixels that don’t intercept Jupiter to an “invisible” sphere is a cool idea... As far as I know, none of the other JunoCam pipelines use this technique.

Most cartographic pipelines map lat/lon on the target into pixel coordinates on the detector, and the mapping in the other direction is typically only used to determine the lat/lon range of the output map. Of course when doing the lat/lon->x,y mapping you have to account for points that are hidden from the camera by the planet itself.

As for the height of the actual limb relative to the 1-bar spheroid -- this is possibly a factor, but the limb is pretty far away even near perijove so it doesn't make a huge difference. For our timing corrections we ignore this.