Project

General

Profile

Bug #5320

Jigsaw failing when lat/lon coordinates are not co-located with disc on image.

Added by Glen Cushing about 1 year ago. Updated 4 months ago.

Status:
Acknowledged
Priority:
High
Assignee:
-
Category:
Applications
Target version:
-
Impact:
Software Version:
Test Reviewer:

Description

Jigsaw fails when it finds no lat/lon value corresponding to the x,y locations of control points within an image--but these data are not required for jigsaw to perform. This is happening with Voyager flyby images of outer-ss moons, where SPICEINIT misses the disk of the target body when placing the disk of lat/lon values into an image. Our work cannot proceed while this issue remains. Brent asked me to submit this ticket -- he can describe the problem more clearly if needed.... Cheers!

History

#1 Updated by Tracie Sucharski 11 months ago

  • Project changed from Jigsaw to ISIS
  • Category set to Applications

#2 Updated by Makayla Shepherd 11 months ago

  • Status changed from New to Acknowledged

#3 Updated by Christopher Combs 10 months ago

  • Assignee set to Christopher Combs

#4 Updated by Christopher Combs 10 months ago

  • Status changed from Acknowledged to In Progress

#5 Updated by Makayla Shepherd 10 months ago

  • Status changed from In Progress to Acknowledged
  • Assignee deleted (Christopher Combs)

#6 Updated by Lynn Weller 10 months ago

  • Assignee set to Christopher Combs

Glenn could you please add more information to post such as the location of the data set you were working with and the actual jigsaw command? What kind of point are in the network (free, fixed, constrained?) It would also be useful to include a brief summary of any pre-processing steps (for instance, are you converting old isis2 nets to isis3 where the data have bad spice in isis3 or did you try to adjust the spice using deltack) and if you tried to run any other programs such as cnetcheck and if so, did they fail on any points/images? Also, does anyone understand precisely what the issue is? I'm concerned a request is being made to "fix" the bundle when the actual problem is bad spice. We can't expect the bundle to accept garbage and work magic. If the points in the bundle are all constrained, then jigsaw will not attempt to calculate the a priori lat/lon/radius, it will use what is provided. If there is a complaint about lat/lon info for a measure then it may be something the bundle is calling which is failing and some serious thought should be put into how the problem is addressed.

Any additional information is appreciated. Thanks!

#7 Updated by Christopher Combs 10 months ago

  • Assignee deleted (Christopher Combs)

Explanation by Brent:

"But yes (as noted by Glen in the ticket) I can generally describe the problem. Briefly, when one has an limb image (e.g. from spacecraft flybys) such that the SPICE data results in the body being in the wrong place in the image, one can have a tie point that the SPICE data calculates as being off the image, so it can not calculate an a priori latitude and longitude, resulting in Jigsaw (and I think other programs) blowing up.

This has been happening in particular with control networks that were created in ISIS2 and are now being imported into ISIS3. The SPICE data was in fact updated in the ISIS2 solutions, but there is currently no way to import it into ISIS3 (it's in a RAND ASCII flat file format). So updating the SPICE itself to fix the problem is not an available solution.

However, the a priori coordinates of the tie points are available and are being read into ISIS3, so jigsaw (when the points are constrained in position) should be using those values for a priori information and not blowing up. But apparently Jigsaw ignores such a priori information (the main bug to be fixed here as I see it) and tries to calculate new a priori info and blows up.

In any case, the a priori information in these global solutions could also be very approximate, e.g. you should always be able to use (0, 0, mean radius) for latitude, longitude, and radius and still get a solution. So a backup/alternate fix (to what is basically a secondary bug) - and one needed in any case if there are no a priori coordinates - would be that if Jigsaw finds a point is off the body according to the SPICE data, instead of stopping it should just use (0,0, mean radius) for the a priori coordinates and go on, and a successful solution will be likely.

This problem seems to have arisen during the conversion of the ISIS2 randlsq program into the ISIS3 jigsaw software, since randlsq did not have these problems.

This is a fairly critical bug for a lot of current and likely future projects, as it makes it difficult to process any flyby /limb images (unless the SPICE data is already very good), and in particular to again process networks that were created in ISIS2. Current, upcoming, and possible upcoming projects affected by this includes mapping of at least Europa, Enceladus, Titan, Bennu (OSIRIS-REx), and Phobos."

#8 Updated by Lynn Weller 10 months ago

However, the a priori coordinates of the tie points are available and are being read into ISIS3, so jigsaw (when the points are constrained in position) should be using those values for a priori information and not blowing up. But apparently Jigsaw ignores such a priori information (the main bug to be fixed here as I see it) and tries to calculate new a priori info and blows up.

I don't think there is a bug in jigsaw in regard to constrained points - this aspect has been tested and confirmed multiple times (someone needs to confirm this). It may there is something jigsaw is calling which is attempting to intersect the target and results in failure.

In any case, the a priori information in these global solutions could also be very approximate, e.g. you should always be able to use (0, 0, mean radius) for latitude, longitude, and radius and still get a solution. So a backup/alternate fix (to what is basically a secondary bug) - and one needed in any case if there are no a priori coordinates - would be that if Jigsaw finds a point is off the body according to the SPICE data, instead of stopping it should just use (0,0, mean radius) for the a priori coordinates and go on, and a successful solution will be likely.

I think this would be a disaster. I have had cases with overall good networks and data with very good spice which has resulted in errors due to only a handful of measures having terrible line/sample information due to terrible registrations. Setting a priori information to (0,0, mean radius) is likely to break even the best data sets.

This is a fairly critical bug for a lot of current and likely future projects, as it makes it difficult to process any flyby /limb images (unless the SPICE data is already very good), and in particular to again process networks that were created in ISIS2. Current, upcoming, and possible upcoming projects affected by this includes mapping of at least Europa, Enceladus, Titan, Bennu (OSIRIS-REx), and Phobos."

It's not clear the actual bug has been identified. But I think passing garbage spice to jigsaw is the bigger issue. We need to get the old smithed data into isis3 to avoid such pitfalls.

#9 Updated by Moses Milazzo 10 months ago

We see programs blow up in many ways when a pixel that SPICE says doesn't intersect a target's surface is run through intersection algorithms. This is the underlying problem: when SPICE is bad, we don't have a way to help ISIS3 learn where the target really is.

In ISIS2 qview had a subprogram called limbfit that allowed one to select a number of points on the limb of an object and calculate a best-fit circle and then update the image SPICE according to that fit. This feature seems to have been lost in the transition from ISIS2 to ISIS3. Having something like this (though I would argue for a best-fit ellipsoid based on the Target) would certainly help with updating SPICE before creating a control network.

Creating such a program or feature in qview/qtie might be a student-level job whereas mucking about in jigsaw to accommodate these errors is clearly not.

Also available in: Atom PDF