too slow for large panos
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Hugin |
Fix Released
|
Low
|
Unassigned |
Bug Description
This is http://
With an increasing number of elements - in my situation, around 200 images with over 6000 control points, the Hugin UI becomse really slow. The key factor seems to be the file serialization of settings. Saving the current state often takes way over one minute to complete. Similarly, operations that seem to cause an automatic save (e.g. for undo?) block the UI, for example checking or unchecking parameters in the optimizer often take multiple seconds to update. For large jobs such as this, this is quite a limitation: it would make sense to incrementally optimize parts of the Panorama to reduce complexity in the optimizer. However, choosing parameters to optimize in the UI is pretty much impossible.
Even worse is the "Layout" view, which only updates with less than one frame per minute (on AMD64 X2 5000+ with 4 GB of RAM, Nvidia graphics). This tool would be useful to detect images that overlap but are not connected via control points - if it would somehow work.
These effects probably are related and can be fixed by checking the data structures the control points are kept in and how they are iterated.
Currently, I can only recommend Hugin for up to ~30 images.
Changed in hugin: | |
status: | New → Fix Committed |
Changed in hugin: | |
status: | Fix Committed → Fix Released |
The time for saving a project is already decreased (see discussion at mailing list http:// groups. google. com/group/ hugin-ptx/ browse_ thread/ thread/ 799cb93699fa852 c# )
But it seems, that the problem with the layout view remains to be solved.