IPB

Welcome Guest ( Log In | Register )

3 Pages V   1 2 3 >  
Reply to this topicStart new topic
Beginner level projection
adamg
post Nov 6 2019, 11:50 PM
Post #1


Junior Member
**

Group: Members
Posts: 24
Joined: 31-October 19
Member No.: 8699



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
Go to the top of the page
 
+Quote Post
Gerald
post Nov 7 2019, 03:21 AM
Post #2


Senior Member
****

Group: Members
Posts: 2281
Joined: 7-December 12
Member No.: 6780



Hi Adam,
I'm not even using the SPICE library. But for anyone being used to the SPICE environment, or for other ways of cross-checking, it would probably be helpful, if you could provide a set of SPICE kernel files you are applying, together with the name of the raw JunoCam image file. This would help to decide, whether your observed deviation from the expected result is caused by the data or by your code (or both). I'd also suggest to read the JunoCam instrument kernel file.
Go to the top of the page
 
+Quote Post
Bjorn Jonsson
post Nov 7 2019, 06:41 PM
Post #3


IMG to PNG GOD
****

Group: Moderator
Posts: 2075
Joined: 19-February 04
From: Near fire and ice
Member No.: 38



In addition to what Gerald mentioned, I'd start by using only the instrument (in this case JunoCam) boresight vector and make sure it intersects Jupiter at the correct location. Once this works correctly you know that any errors are elsewhere (e.g. in how you map individual pixels to rays in 3D space).

Also if you haven't done so it might also be a good idea to first make sure your code works correctly for a camera that is less complicated to handle than JunoCam. A framing camera (e.g. Cassini) is easier.
Go to the top of the page
 
+Quote Post
mcaplinger
post Nov 7 2019, 10:53 PM
Post #4


Senior Member
****

Group: Members
Posts: 1936
Joined: 13-September 05
Member No.: 497



QUOTE (adamg @ Nov 6 2019, 03:50 PM) *
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'm not sure what you're trying to do (not following the "invisible sphere" stuff) and I have the suspicion that you're counting the light time twice, but all that said there are known timing errors of roughly six pixels 1 sigma in the Junocam start time that you need to correct for. We're working on pushing updates to the PDS but it'll probably be a while before that happens. In the meantime, which images are you working with?

Also, make sure you are using the reconstructed SPK files.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
adamg
post Nov 7 2019, 11:16 PM
Post #5


Junior Member
**

Group: Members
Posts: 24
Joined: 31-October 19
Member No.: 8699



Thanks for the replys. I actually did start off using the boresight vector and it certainly looked like I was on the right track. Then I moved to looking for the edge of the planet from the undistort method in the IK and including the bias delay it looked pretty good other than being off by an additional delay (yes, I've definitely been through the IK file). I was assuming it was clock drift but later noticed it was similarish to the light time so I'm wondering if I'm not correcting for light times properly. I added the found image to this post where red means it didn't find Jupiter in that pixel's direction.

My kernal uses the following files:
\begindata
KERNELS_TO_LOAD = ( 'naif0012.tls','JNO_SCLKSCET.00092.tsc','de438s.bsp',
'jup310.bsp','juno_rec_orbit.bsp','juno_struct_v04.bsp','juno_v12.tf',
'juno_junocam_v03.ti','pck00010.tpc','juno_sc_nom_110807_171016_v01.bc' )
\begintext
And I'm using image JNCR_2017244_08C00109_V01.IMG

I attached the point cloud the first few framelets make and it looks reasonably hopeful. It got really ulgy really fast when I tried making that imaginary sphere to map the planet misses onto. You can see the planet on the right and the sphere way off on the left not attached so I've obviously messed up my SPICE calls. I've had a pretty hard look and I think it's my failure to grasp something rather than a simple coding error. My guess is I actually have two separate problems, one in my attempt to make an imaginary sphere just by multiplying a direction vector and the other in my light time correction flag for the sincpt call. That's why I just added those calls in the post.

Thanks again.

Adam
Attached thumbnail(s)
Attached Image
Attached Image
Attached Image
 
Go to the top of the page
 
+Quote Post
mcaplinger
post Nov 7 2019, 11:24 PM
Post #6


Senior Member
****

Group: Members
Posts: 1936
Joined: 13-September 05
Member No.: 497



QUOTE (adamg @ Nov 7 2019, 03:16 PM) *
'juno_sc_nom_110807_171016_v01.bc'

Don't use the nom C kernels, use the rec C kernels.

Our measurements show that the timing for that image was off by 3 pixels or 3*3.2 milliseconds.

Not important, but still not following the invisible sphere stuff.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
adamg
post Nov 7 2019, 11:27 PM
Post #7


Junior Member
**

Group: Members
Posts: 24
Joined: 31-October 19
Member No.: 8699



QUOTE (mcaplinger @ Nov 7 2019, 11:53 PM) *
I'm not sure what you're trying to do (not following the "invisible sphere" stuff) and I have the suspicion that you're counting the light time twice, but all that said there are known timing errors of roughly six pixels 1 sigma in the Junocam start time that you need to correct for. We're working on pushing updates to the PDS but it'll probably be a while before that happens. In the meantime, which images are you working with?

Also, make sure you are using the reconstructed SPK files.


Just to explain that sphere thing, my plan is to map every pixel to a point in space and then turn it back to an image from nearst points to vectors coming from the spacecraft's location. So the points not mapped to a planet need to get mapped somewhere nearish so I thought a sphere centered on Juno and intersecting with the middle of Jupiter would be some kind of start.
Go to the top of the page
 
+Quote Post
adamg
post Nov 7 2019, 11:30 PM
Post #8


Junior Member
**

Group: Members
Posts: 24
Joined: 31-October 19
Member No.: 8699



QUOTE (mcaplinger @ Nov 8 2019, 12:24 AM) *
Don't use the nom C kernels, use the rec C kernels.

Our measurements show that the timing for that image was off by 3 pixels or 3*3.2 milliseconds.

Not important, but still not following the invisible sphere stuff.


Thanks for the timing error, that means it's definitely misuse of SPICE, my error is similar to the light time (230 odd ms).
Go to the top of the page
 
+Quote Post
mcaplinger
post Nov 7 2019, 11:51 PM
Post #9


Senior Member
****

Group: Members
Posts: 1936
Joined: 13-September 05
Member No.: 497



QUOTE (adamg @ Nov 7 2019, 03:30 PM) *
Thanks for the timing error, that means it's definitely misuse of SPICE, my error is similar to the light time (230 odd ms).

Keep in mind that SPICE is computing the distance to the center of Jupiter, not to the visible surface, so if you're using the former when you mean the latter, there's an error there, which if you're close to the planet is a pretty big error.

Try not doing any light time correction at all. See the cautionary note in the comments for the sincpt function, etc.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post Nov 8 2019, 07:17 AM
Post #10


Member
***

Group: Members
Posts: 127
Joined: 18-September 17
Member No.: 8250




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
Go to the top of the page
 
+Quote Post
mcaplinger
post Nov 8 2019, 03:27 PM
Post #11


Senior Member
****

Group: Members
Posts: 1936
Joined: 13-September 05
Member No.: 497



QUOTE (Brian Swift @ Nov 7 2019, 11:17 PM) *
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.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Gerald
post Nov 8 2019, 04:39 PM
Post #12


Senior Member
****

Group: Members
Posts: 2281
Joined: 7-December 12
Member No.: 6780



QUOTE (adamg @ Nov 8 2019, 12:27 AM) *
... I thought a sphere centered on Juno and intersecting with the middle of Jupiter would be some kind of start.

Be sure, that you don't use a sphere, but a Maclaurin spheroid with the proper polar and equatorial radii, and with the correct axis tilt. You should then ideally end up with an error of less than 100 km induced by deviations due to Jupiter's internal mass distribution and dynamics, and due to the uncertainty of the pressure level of Jupiter's cloud tops. Using a sphere of some mean radius would cause errors on the order of 2000 km.
Go to the top of the page
 
+Quote Post
Brian Swift
post Nov 8 2019, 05:56 PM
Post #13


Member
***

Group: Members
Posts: 127
Joined: 18-September 17
Member No.: 8250



QUOTE (Gerald @ Nov 8 2019, 08:39 AM) *
Be sure, that you don't use a sphere...

The sphere being discussed here is not a model for Jupiter's shape, it is a synthetic surface onto which imagery that does not intercept Jupiter can be projected.
Go to the top of the page
 
+Quote Post
adamg
post Nov 9 2019, 12:15 AM
Post #14


Junior Member
**

Group: Members
Posts: 24
Joined: 31-October 19
Member No.: 8699



We're totally on the same page Brian.

The help funtion returns sincpt(method, target, et, fixref, abcorr, obsrvr, dref, dvec) which matches the C spice documentation so the penultimate item is the frame for the direction vector which is JUNO_JUNOCAM. While I wait for the Mathematica viewer to download I'm going with mcaplinger's suggestion of forgetting about light correction for a first pass and your suggestion of working in the IAU_JUPITER frame. I couldn't tell if you were doing some clever way of intercepting so I just subtracted the scaled pixel vector from the planet-juno separation. I do think my frames weren't right before so I'm refactoring it now to go into the IAU_JUPITER mostly because sincpt says it only works with the body centered frame so that's the least amount of jiggering. I didn't correct for the limb thinking it would only give a smallish error but I see everyone pointing out how far off this will be. In my defence you see all these planet sphere type pictures so I had no idea how close that thing gets!

Just to share, the black thing is the sphere that intersects with the middle of Jupiter and has an origin at Juno and you can see how far away the limb is from there. I switched to open3d rather than matplotlib as a viewer and I have to say being able to rotate the point cloud in real time is pretty awesome.

Thanks for everyone being so helpful and that other post is very interesting.
Attached thumbnail(s)
Attached Image

 
Go to the top of the page
 
+Quote Post
Brian Swift
post Nov 10 2019, 07:40 AM
Post #15


Member
***

Group: Members
Posts: 127
Joined: 18-September 17
Member No.: 8250



QUOTE (mcaplinger @ Nov 7 2019, 03:51 PM) *
Keep in mind that SPICE is computing the distance to the center of Jupiter, not to the visible surface, so if you're using the former when you mean the latter, there's an error there, which if you're close to the planet is a pretty big error.

Try not doing any light time correction at all. See the cautionary note in the comments for the sincpt function, etc.

As I read the cautionary note, it only applies in the situation where DREF is same as FIXREF.

From ABCORR description in sincpt doc:
QUOTE
For remote sensing applications, where the apparent surface intercept point seen by the observer is desired, normally the correction 'CN+S' should be used.

'LT+S' trades some accuracy for speed, which may be relevant if calling sincpt for every pixel.
Go to the top of the page
 
+Quote Post

3 Pages V   1 2 3 >
Reply to this topicStart new topic

 



RSS Lo-Fi Version Time is now: 26th May 2020 - 09:45 AM
RULES AND GUIDELINES
Please read the Forum Rules and Guidelines before posting.

IMAGE COPYRIGHT
Images posted on UnmannedSpaceflight.com may be copyrighted. Do not reproduce without permission. Read here for further information on space images and copyright.

OPINIONS AND MODERATION
Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators.
SUPPORT THE FORUM
Unmannedspaceflight.com is a project of the Planetary Society and is funded by donations from visitors and members. Help keep this forum up and running by contributing here.