On 26 Mai, 21:04, gridrix <hendrik.siedelm...@googlemail.com> wrote: > Are there any devs in this ML? > > I really like hugin but it seems to scale very bad with many images. > Any comments? It looks like something that was done not very scalable > because it was good enough, but it does create problems with very many > images.
Be a bit more specific about which parts you feel are particularly slow. And it may help in the analysis to identify if it's hugin per se or one of the programs/libraries it uses for various tasks that's slowing things down. I suppose, though, that you actually mean hugin itself. Many images usually slow things down if every image is somehow put in relation to every other image. Then processing time may rise quadratically. You can't avoid a certain slowdown with increase in image numbers if the images are somehow put in relation - N is usually too optimistic and N log N is probably quite good already - depending on which partial problem you're looking at. Add to that slowdown from a larger memory footprint. But when it comes to a GUI, of course simple techniques can produce slowdowns which grow out of proportion with large amounts of images, and even N is not acceptable. Your initial complaint about disabling single images in the preview would fit in here - it shouldn't really matter how many images are there if you switch a specific one on or off. Slowdowns here might point to programming behaviour like 'an image has been removed - look at all other images and see if the removed image overlapped with them (by looking at all points in both images to see if any are in the same place) - if so do something' instead of, say, 'look up the images that overlap from a precalculated overlap database and take it from there'. I suspect there are skeletons of this kind in hugin's cupboard. Your profiling seems to point that way as well. I think one reason for stuff like this happening is that internally a lot of stuff is done with arrays and indices (like, old C-style arrays) which scales badly. A lot of stuff going on is probably done by some ancient bit of C code in a library somewhere, which was written when noone thought of the scales we're working at now, and without the STL for containers. And the whole show started out as a GUI for a bunch of other programs doing the 'real' work, not as an image-processing software per se. In the end you have several choices in the matter. Work your way around the deficiencies you can't accept, ask for improvements in specific places or become involved and fix it for yourself - and hopefully for everyone else as well. Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
