hugin slow with many images

[gridrix]

Hello everybody,

first I want to say thank you to all the people working on hugin, it's
a great program that I use a lot.
The problem is that I recently built a panorama-roboter with
fischertechnik, and after a test run I tried to build the panorama
with hugin. I used cpfind in multirow mode to create the control
points.
Opening the panorama, showing the preview is of course slower, but
reasonably so.
However if I try to disable or enable single images in the preview
window, or when I try to disable parameters in the optimizer tab hugin
hangs busy for tens of second for every single action I do. I did a
debug build of hugin and started to do some profiling with oprofile,
and it seems to spend 99% of its time in
HuginBase::ImageVariable<hugin_utils::TDiff2D<double>
>::searchForwards(HuginBase::ImageVariable<hugin_utils::TDiff2D<double>
> const*) const
in the api documentation there is a comment about the ImageVariable
stuff being slow, so is there a chance of speeding this up?

[Jeffrey Martin]

Will you show us your robot? :-)

here is the one i use to make gigapixels
http://www.flickr.com/photos/jeffrey-martin/5617720940/in/photostream

(according to my son)

:-)

[gridrix]

Here it is:
http://w3studi.informatik.uni-stuttgart.de/~siedelhk/pantalaimon.jpg

There camera is mounted between the two big gears you see at the top.
I'll try to get a second camera to show how it looks in action. It's
quite fast, 2-3s per picture and most of the time is waiting for it to
focus and pressing the trigger. The accuracy is around 0,7 degrees for
both axis.
Sadly cable remotes are not supported by my Olympus e-500, so the
release is also triggered mechanically which is quite slow.

[gridrix]

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.

[kfj]

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

[Jan Martin]

I guess the slow down is from Control Point Finders testing every image against every other image. Seems even brand new "Hugins CPFind" does things this way?

I never understood why one cannot have a way to tell hugin that there are

x images around
y images up, y1 degrees
z images down, z 1 degrees

(Or extract this info from yaw, pitch and roll values from the "Images" tab and "degrees of view" from "Camera and Lens" tab.)

This gives a very precise idea of where image pairs overlap to place CPs in that overlap only, and which images to compare with each other:

Example: 4 around, 1 up:
0 > 1 > 2 > 3 > 0
0 > 4
1 > 4
2 > 4
3 > 4

A few sensible defaults to pick from should speed things up significantly.

Jan

Please tell when I am totally wrong.

--
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 hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

--
http://www.DIY-streetview.org

[Carlos Eduardo G. Carvalho (Cartola)]

That's why I am doing CPs like these (win example) on a bat file:

REM ##### Enfuse
enfuse -o 01.jpg IMG_0954.JPG IMG_0955.JPG IMG_0956.JPG
enfuse -o 02.jpg IMG_0957.JPG IMG_0958.JPG IMG_0959.JPG
enfuse -o 03.jpg IMG_0960.JPG IMG_0961.JPG IMG_0962.JPG
enfuse -o 04.jpg IMG_0963.JPG IMG_0964.JPG IMG_0965.JPG
enfuse -o 05.jpg IMG_0966.JPG IMG_0967.JPG IMG_0968.JPG
enfuse -o 06.jpg IMG_0969.JPG IMG_0970.JPG IMG_0971.JPG
enfuse -o 07.jpg IMG_0972.JPG IMG_0973.JPG IMG_0974.JPG
enfuse -o 08.jpg IMG_0975.JPG IMG_0976.JPG IMG_0977.JPG
enfuse -o 09.jpg IMG_0978.JPG IMG_0979.JPG IMG_0980.JPG
enfuse -o 10.jpg IMG_0981.JPG IMG_0982.JPG IMG_0983.JPG
enfuse -o 11.jpg IMG_0987.JPG IMG_0988.JPG IMG_0989.JPG

REM ##### Round
autopano-sift-c --maxmatches 10 out01.pto 01.jpg 02.jpg
autopano-sift-c --maxmatches 10 out02.pto 02.jpg 03.jpg
autopano-sift-c --maxmatches 10 out03.pto 03.jpg 04.jpg
autopano-sift-c --maxmatches 10 out04.pto 04.jpg 05.jpg
autopano-sift-c --maxmatches 10 out05.pto 05.jpg 06.jpg
autopano-sift-c --maxmatches 10 out06.pto 06.jpg 07.jpg
autopano-sift-c --maxmatches 10 out07.pto 07.jpg 08.jpg
autopano-sift-c --maxmatches 10 out08.pto 08.jpg 01.jpg

REM ##### 1 top + 2 down
autopano-sift-c --maxmatches 10 out09.pto 09.jpg 01.jpg
autopano-sift-c --maxmatches 10 out10.pto 10.jpg 01.jpg
autopano-sift-c --maxmatches 10 out11.pto 11.jpg 10.jpg

REM ##### Final join
pto_merge -o 01-11.pto out01.pto out02.pto out03.pto out04.pto out05.pto out06.pto out07.pto out08.pto out09.pto out10.pto out11.pto

Its not difficult to make a unix or a php script to generate this BAT file (my BAT programming knowledge is limited) or a sheel script to make it all. I've been thinking of making a php to generate it on-line to windows bat or unix shell with parameters like which images are horizontal or even with a free pair association, optional complete path of programs (if they are not in command path), optional enfuse, etc.

[ ]s, Cartola.

2011/5/26 Jan Martin <janm...@diy-streetview.org>

[Yuval Levy]

On May 26, 2011 04:16:26 PM Jan Martin wrote:
> I never understood why one cannot have a way to tell hugin that there are
>
> x images around
> y images up, y1 degrees
> z images down, z 1 degrees

because
1. nobody has been bothered enough to do it;
2. there are too many special cases and exceptions to the regular shooting
pattern;
3. programmers are lazy and prefer a program that does it for them;
4. technology has moved forward and made such a feature less desirable (or
even obsolete in the opinion of some - not IMHO).

Current status of the technology is that using cpfind with the multi-row
strategy will solve this for most use cases, and because of reason (3) most
programmers will consider the multi-row strategy approach to be superior to
the approach of user entry.

Indeed it works for many (most?) cases and I also think it is superior, when
it works. I would like to have the alternative of manual entry, but the devil
is in the detail:
* is the shooting clockwise or counterclockwise?
* top to bottom or bottom to top?
* do really all rows have the same number of shots? in some projects yes, in
others not (zenith and nadir are technically rows with a single shot)
* how to deal with trigger errors (duplicates / extra shots)?

all of this calls for a nice canvas on which the user can lay out rows and
columns, giving the yaw/pitch stepping for the application to sort the
sequence of images into this calculated grid and letting the user drag / drop
the exceptions until happy and before feeding into the CP generator.

Too much work for a programmer. The multi-row strategy takes care of this
most (but not all) of the times.

In the past there was a similar situation with HDR stacks. Tim hacked a
manual interface for it [0]. And yet it did not make it into Hugin. Instead
James' new layout GSoC 2008 project introduced the concept of stacks into the
software, making the "facilitated manual work" redundant.

> Please tell when I am totally wrong.

You are not totally wrong. You are describing a "facilitated manual work"
strategy, where effort is put into designing an interface that makes it easy
for the user to generate an initial distribution, which in turn makes it easy
for the CP generator to do its work on the pre-distributed images.

The bad news is that programmers are more attracted by "no manual work"
strategies, and the multi-row option in cpfind is just that.

The good news is that with the Python scripting every user will have the
opportunity to script the feature you are asking for.

Yuv

[0] http://ultrawide.wordpress.com/2008/11/16/hacking-hugin-part-1/

[Yuval Levy]

On May 26, 2011 04:43:37 PM Carlos Eduardo G. Carvalho (Cartola) wrote:
> That's why I am doing CPs like these (win example) on a bat file:

> REM ##### Enfuse
> enfuse -o 01.jpg IMG_0954.JPG IMG_0955.JPG IMG_0956.JPG

...

#!/bin/bash

SOURCE="."
SUFFIX="JPG"
step=3
s=1
fuse_list=""

for i in "$SOURCE"/*.$SUFFIX
do
# extract filename before suffix
l=`echo ${i%%.$SUFFIX} |sed 's#^.*/##'`
fuse_list[$s]="$l.$SUFFIX "
echo ${fuse_list[$s]}

if [ "$s" = "$step" ]; then
fuse_target="$fuse_target$l.jpg"
enfuse --contrast-weight=1 \
--output=$fuse_target ${fuse_list[1]} ${fuse_list[2]} ${fuse_list[3]}
exiftool -TagsFromFile ${fuse_list[1]} $fuse_target
s=0
fuse_list=""
fi

if [ "$s" = "1" ]; then
fuse_target=$l
fi
s=$[$s+1]
done

> REM ##### Round
> autopano-sift-c --maxmatches 10 out01.pto 01.jpg 02.jpg

...

panostart -o bootstrap.mk *.jpg
make -f bootstrap.mk
cpfind --multi-row -o pointless.pto project.pto

in most (not all) cases the resulting project.pto is the same or better than
with all the list of autopano-sift-c calls; and the multi row strategy does
what all the list does, in one single command.

> Its not difficult to make a unix or a php script to generate this BAT file

even less difficult to let cpfind do its magic and intervene manually only in
those border cases that it fails.

and users will have one extra option now with Python scripting.

Yuv

[Carlos Eduardo G. Carvalho (Cartola)]

Thanks! Will try them.

2011/5/26 Yuval Levy <goo...@levy.ch>