findfeatures - "Failed to get geometry mapping" error

[lwellerastro]

Running findfeatures via isisminer and cluster jobs using isis3beta2018-09-18 (and I think last weeks run was under the beta public release - error there as well).

I get the following error for 7 images: Program = findfeatures Class = "PROGRAMMER ERROR" Code = 3 Message = "Failed to get geometry mapping for

See example under /work/users/lweller/Isis3Tests/FindFeatures/GeometryError/. LOG file in the top directory is stdout/err captured via slurm (ignore the rsync failures - directories didn't exist).

The input fromlist, debuglog and isisminer _matcher.cmd files are under the subdirectory N1489047533_2_Network/. The match image with full path can be found in the LOG, print.prt and matcher.cmd files. Any reference file on my /scratch area have since been moved, but everything necessary to duplicate is available.

I have not tried to rerun these failed images outside the cluster environment, but I suspect they would fail as well on the astrovm.

[jessemapel]

I did a quick search and this error message means that there were not enough matches to compute the transformation from one image into another. Your debug logs look like they are missing things. I'd expect logs that look like the log at the end of the findfeatures documentation.

[lwellerastro]

I reran the command on a work directory and debug is essentially empty - agreed it should not look like that. But if there are not enough matches shouldn't it report it, sort of like this run/debug file:

Entered RobustMatcher::symmetryTest(matches1,matches2,symMatches)...
 -Running Symmetric Match tests...
  Total Input Matches1x2 Tested: 0 x 0
  Total Passing Symmetric Test:  0
  Processing Time:               0

I have a lot of this sort of thing with my data, but it always seems to get reported. findfeatures will even go on and try the homography and epipolar with no matches and report the failures there. Are we sure nothing else is going on?

[jessemapel]

So I looked some more and it's erroring out during the computation of the fastgeom transformation. Basically it reprojects all of the train images into the match image prior to matching. It couldn't find enough common points to do that.

I don't know much about the fast geom code, so I don't know if I can help more than that.

The good news it that it is correct in not outputing a full debug log because this happens before it starts writing the majority of the log out.

[lwellerastro]

The fromlist passed to findfeatures (FF) for this case contains 240 entries, and the image reported in the error message is number 223 in that list. Nothing is going to the debug log other than the basic heading information which tells me this one image that has a fast geom problem is killing the entire process. Bummer.

It seems like FF is getting all of the overlaps in place for all of the images in the fromlist before it attempts keypoints, matching, etc., and if it has a problem dies horribly. It should really just report and skip the offending image so that the successful fast geom-ed images can go through the matching process.

I'll chuck the image from the list and rerun things and see how it goes. I will also take a look at the match and from image it is failing on in qnet (w/ geom on) to see what it looks like there.

Thanks for taking a closer look Jesse.

[lwellerastro]

I have reviewed all of the failure pairs and although footprint comparisons say they overlap, I can't find where. They were accidentally being passed to findfeatures because of a typo on the overlap ratio test which was testing on 0.0055 instead of the intended 0.055.

A better way to avoid poor overlaps like these pairs is to trim the footprint based on high incidence and emission angles keeping them from ever being regarded as overlapping in the first place. I was testing on a set of images with no exclusions but a second set where I had avoided high inc and ema has confirmed they don't even make it to my overlap list.

So I can avoid these images pairs, but I think findfeatures needs to handle these types of situations better.

[jessemapel]

@lwellerastro That sounds like a good place to improve the application. I'm going to create a feature request for this.

[lwellerastro]

That test directory is not set up for user ease, so I can make that more straight forward if necessary. Just let me know.