Spiceinit - spice not really there for some Voyager images

[lwellerastro]

I have a handful of Voyager images that have successfully gone through spiceinit (no errors or warnings) that appear to have no spice within the image frame. When camstats is run on these images all of the output values are NULL.

Two images that have this problem can be found under /work/users/lweller/Isis3Tests/Spiceinit/Voyager/. Both of the images have the following processing steps applied:

voy2isis
spiceinit extra=/usgs/cpkgs/isis3/data/base/kernels/pck/pck00010_msgr_v23.tpc
voycal

We have to point to a specific pck file because default spice applies kernels based on mission/instrument information and not by target body so we get the wrong information otherwise (these are images of Europa to be combined with Galileo images of the same target).

These images were intended to be included in the new global mosaic of Europa being worked on this FY year. Both of these images were in the original network and mosaic due to their high quality and we would like to include them in an updated product, but it may not be possible.

It would be great if someone could look into this and at the very least help us to understand what is going on in the event there is no resolution to the problem. Thanks!

[krlberry]

Hi Lynn, Not sure what's happening yet, but I can reproduce the problem using your test data. Could you add a Voyager image from your project that doesn't have this problem to your /work/users/lweller/Isis3Tests/Spiceinit/Voyager/ directory for comparison purposes?

[lwellerastro]

Check out c2059319.cal.cub which should be close in time to c2059317. I can find one close in time to c2061215.cal.cub if that helps.

[krlberry]

For the c2059317.cub image, the reason there is no spice within the image frame is because the used spice kernels are so far off that it identifies Europa as existing outside of the entire image frame. That being said, newer spice kernels for Voyager 2 are available, and I'm investigating if updating these fixes the problem.

[jlaura]

I just spoke with @lwellerastro. If it looks like we are going to close this, it might be best to get an enhancement request in for deltack.

[krlberry]

For update's sake: I tried updating the kernels (locally) to the newest available and the pointing is still off the frame of the image. Is it worth updating the voyager kernels used in the system? @jlaura What would the enhancement request be for deltack?

[lwellerastro]

Thanks for looking into that @kberryUSGS - the conversation was more like "this probably isn't going to pan out, better look to another direction for a solution", and I was anticipating you would be given the opportunity to come up with some conclusions, good or bad. If the updated kernels you tested are better in anyway, we may want to get them into the system. Although they may not solve my current problem, they could certainly benefit future work. I'd like to better understand what has been updated.

Question in regard to the "new" kernels - which kernels were updated (ck and/or spk)?

I had initially tried to run deltack on the image by tieing it to another overlapping image that had spice on the target, but that program failed, presumably because there was no spice in the scene. Jay and I talked about maybe addressing the problem there, but after thinking about that, I don't think that is worth the time - I just don't see a solution there. The issue seems to be more of an isis thing and less of a specific application thing.

The one thing that will absolutely fix this problem is for #2591 to be addressed. The images that have this problem are in an old network that contain adjusted lat/lon/radius values that the images could be forced to via jigsaw if it weren't for a current limitation in that application.

[jessemapel]

I agree with @lwellerastro, fixing #2591 is probably the best solution for this.

[blandoplanet]

@jlaura: In the meantime @scsides, with input from @lwellerastro, has identified a possible work around. Since the two images described above were used in a previous network they presumably have improved SPICE. It might be possible to convert the RAND output to ck kernels and then convert them to continuous kernels using NAIF software. It might be useful if @scsides takes some time to dig into whether this is feasible.

Thoughts?

[jlaura]

@ALL I am going to close this as #2591 has been merged and it is clear that the issue is a SPICE related one. We can reopen if appropriate, but for now, no fix is possible given how bad the initial SPICE is.

[krlberry]

@jlaura 👍 I'd left this open in case something came out of the comment about using the RAND output, but going down that path would probably be a different ticket. To answer @lwellerastro's questions about what changed in the updated SPICE, I'll go over to #1242

[lwellerastro]

@kberryUSGS , that works - thanks for pointing me in the right direction!