Hugin appears to be non-deterministic?

[Spencer Egart]

I'm stitching images via script, and have noticed that every time I run it I get a slightly different final pano.  I'm making sure to delete any old intermediate .pto files beforehand, so it's not that.

Are any of the tools in Hugin (autooptimiser, cpfind, etc.) based on random/non-deterministic algorithms?  If so is there a way to seed the RNG or in some other way ensure reproducible results? 

[Bruno Postle]

On 22 October 2014 21:48:17 BST, Spencer Egart wrote:
> I'm stitching images via script, and have noticed that every time I
> run it I get a slightly different final pano. I'm making sure to delete
> any old intermediate .pto files beforehand, so it's not that.
>
> Are any of the tools in Hugin (autooptimiser, cpfind, etc.) based on
> random/non-deterministic algorithms?

The photometric optimisation samples random pixels. Everything else should be the same for consecutive runs (untested).

> If so is there a way to seed the RNG or in some other way ensure
> reproducible results?

Not currently, this seems like a good idea.


--
Bruno

[Brandon]

Enblend is the tool that figures out where to blend the lines, it seams to have a randomness when figuring some parts of where to blend photos together. I have tested it a lot and near as I can tell that is the only part in my work flow that changes much and it is just a little here and there. Most of the time it is not noticeable. If that is a problem you might try multiblend I have not messed with it much but I do know it works differently and it may give you consistent results. Also check the documentation on enblend, there may have been mention of the seed generator in there.

[Spencer Egart]

I wonder then if anyone can tell me what I'm doing wrong, because I'm getting extremely different results every time.  I have a template for the camera orientations which I'm setting via pto_var, but would like to fine-tune that via control points.  I'm running the following script on a set of 8 images:

#! /bin/sh
FOV=125.2430276873036


pto_gen --projection=0 --fov=$FOV -o project1.pto "$@"
pto_var -o project1.pto --set  y0=-2.0,r0=-91.0,p0=4.5,y1=142.7,r1=-88.5,p1=3.8,y2=88.7,r2=-87.0,p2=0.4,y3=135.0,r3=-88.0,p3=-3.3,y4=179.0,r4=-89.0,p4=-1.8,y5=225.0,r5=-92.0,p5=-3.0,y6=266.8,r6=-95.0,p6=-0.0,y7=312.0,r7=-93.7,p7=1.2 --opt y,p,r project1.pto
cpfind --prealigned -o project1.pto project1.pto
cpclean -o project1.pto project1.pto
linefind -o project1.pto project1.pto
autooptimiser -l -n -o project1.pto project1.pto > /dev/null
pano_modify --projection=2 --fov=AUTO --center --canvas=AUTO --crop=AUTO -o project1.pto project1.pto
pto2mk -o project.mk -p pano project1.pto
make -j 12 -f project.mk all

[Terry Duell]

Hello Spencer,

On Tue, 28 Oct 2014 05:07:25 +1100, Spencer Egart <spen...@google.com>
wrote:

> I wonder then if anyone can tell me what I'm doing wrong, because I'm
> getting extremely different results every time. I have a template for
> the
> camera orientations which I'm setting via pto_var, but would like to
> fine-tune that via control points. I'm running the following script on a
> set of 8 images:
>

If I understand this correctly, you can run this script a number of times
with the same input images, and the resulting panos are quite different.
looking over the script nothing was obvious, so I ran a little test using
3 of my own images and the script modified only to reflect the y,p,r
values of the input images.
The results vary only very slightly. Comparing the pto files from two runs
I see only one control that is different. I can't visually detect any
difference in the resulting panos.
My script and the pto files from two runs are attached.
I am running hugin-2014.1.0, a build of the current hugin_executor branch.
Do you provide your input images in the same order each time? Changing the
order that the input images are passed to the script will alter the anchor
image, and hence the optimisation results.
Do you get the same result using subsets of the images?
If you don't have any success on this can you provide (say) the first 3
images and the current script at that time (via Dropbox or similar?) for
us to try to reproduce the problem?

Cheers,
--
Regards,
Terry Duell

[Terry Duell]

On Tue, 28 Oct 2014 09:04:10 +1100, Terry Duell <tdu...@iinet.net.au>
wrote:

> Do you provide your input images in the same order each time? Changing
> the order that the input images are passed to the script will alter the
> anchor image, and hence the optimisation results.

Sorry, not thinking...of course you must provide your images in the same
order every time...otherwise your settings for y,p,r to pre-assemble would
be all haywire.

[T. Modes]

Am Montag, 27. Oktober 2014 19:07:26 UTC+1 schrieb Spencer Egart:

#! /bin/sh
FOV=125.2430276873036
pto_gen --projection=0 --fov=$FOV -o project1.pto "$@"

This look suspicious for me. A rectilinear ("normal") lens with a HFOV of 125 deg is very unusual. This would correspond to a focal length of 9 mm (35 mm equivalent). Are you sure that this is correct?

Also

pto2mk -o project.mk -p pano project1.pto
make -j 12 -f project.mk all

looks suspicious. You are calling many programs parallel, but each program is using all cores at the same time. This can result in conflict of resources.
Either call pto2mk + make (-j 1) or you have to take cautions that each program is only using one core (for nona -t switch and for enblend/enfuse environment variable omp_num_threads)