autopano-sift-c crashes with very wide photos
Bug #679398 reported by
Bruno Postle
This bug affects 2 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| autopano-sift-c |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
With autopano-sift-C 2.5.1
An 8mm fisheye on a full size sensor produces a landscape orientation photo with an angle of view of 260 degrees, calling apsc like this results in no features identified and a segfault:
autopano-sift-c --projection 2,260 output.pto *.JPG
The transition is sudden: 223, 224, 225 degrees are fine and hundreds of features are detected. 226 degrees and above and 0 features are detected and matching produces a segfault.
| tags: | added: autopano-sift-c fisheye projection |
| Changed in hugin: | |
| importance: | Undecided → Medium |
| status: | New → Triaged |
Revision history for this message
| Felix Hagemann (flixh) wrote | #1 |
| Changed in hugin: | |
| status: | Triaged → Confirmed |
| affects: | hugin → autopano-sift-c |
To post a comment you must log in.
With a current snapshot this happens as well. Occurs with portait images of 2920x4386 when going from 199 degrees to 200 degrees fov. I have spend a bit of time trying to hunt this bug down. Preliminary result:
1. During image remapping in saRemap.c, saRemap_new(...) x[i] in this line
y[i] = CamLens_RofA( pd, CamLens_AofR( ps, x[i] ) )
becomes > Pi.
2. Therefore the calls to CamLens_RofA( pd, CamLens_AofR( ps, x[i] ) ) (itself calling a2r_ster which calculates tan(0.5 * x[i] ) returns a negative value for y[i].
3. The negative value for y[i] makes the monoticity test of the following spline evaluation fail, making the whole saRemap_new return 0 and autopano-sift-c segfault when saRemap_inv tries to dereference the null pointer.
Questions:
A comment in CamLens.c indicates that A (or x[i] in the above) should be < Pi for stereographic projection. Does this make sense? How did we end up with it being greater? Why does this trigger at fov > 199 in portrait and >225 in landscape?
Should we just remap all x > pi to x = pi to get rid of the problem?
Sorry for the chaotic braindump above, I need to go to sleep now and need to write the stuff down, otherwise a start from scratch is needed when I'm looking at the problem again.
Regards
Felix