Running geometric optimizer after stitcher producing drastically different result

Bug #1856345 reported by Sergei Steshenko
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Hugin
Invalid
Undecided
Unassigned

Bug Description

The more detailed summary: running geometric optimizer after stitcher, but on the same input data produces drastically different result.

The testcase uses the same input data as in bug #1856336. The system is the same and the instructions to download input data are the same. Input data and evidence can be found under https://cloud.mail.ru/public/NN3V/2x8jVAS9n .

As in bug #1856336 the 8 input .NEF files were imported the usual way through the "Photos" window - see 'photos_window.png' file in the above web folder.

Then control points were detected automatically - see the 'photos_window.png' file for details.

Then geometric optimizer was run - see the 'photos_window.png' file for details. The optimizer produced a report - see 'first_optimizer_report.png' file in the above web folder. In the report one can see, for example, "maximum: 7.041825".

Then photometric optimizer was then run.

Then "Stitcher" tab was clicked and stitcher parameters were set - see 'stitcher_window.png' file in the above web folder for details. In the stitcher window "Calculate Field of View" and "Calculate Optimal Size" were clicked.

When stitcher finished its run again "Photos" tab was clicked and in it geometric optimizer was run again (by clicking its "Calculate" button). The second run produced a different from the first run result - see 'second_optimizer_report.png' file in the above web folder for details. In the report one can see among other things "maximum: 84.440525". I.e. the second report maximum is more than order of magnitude bigger than the first one. IMO consecutive run of a program on the same input data should produce the same output data - unless there is randomization.

Revision history for this message
tmodes (tmodes) wrote :

The control point error distances are calculated in the output space. When you change the output size (or projection), it is expected that the cp error distance changes. (This is a design decision in the underlying panotools library.)

Changed in hugin:
status: New → Invalid
Revision history for this message
Sergei Steshenko (sergstesh) wrote :

"The control point error distances are calculated in the output space" - which action of mine changes output space ?

Revision history for this message
tmodes (tmodes) wrote :

> In the stitcher window "Calculate Field of View" and "Calculate Optimal Size" were clicked.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.