Control point generator incantations

[Bruno Postle]

Hugin-2009.2.0 has the ability to configure multiple control point
generators. Currently the default and only control point generator
setup is:

"Autopano-SIFT-C", "autopano-sift-c", "--maxmatches %p %o %i"

Though actually you should get better results with these extra
parameters as it enables feature classification in conformal space:

"Autopano-SIFT-C", "autopano-sift-c", "--maxmatches %p --projection %f,%v %o %i"

There is a newer, cleaner interface that also enables the conformal
space thing, this involves passing a .pto project as input:

"Autopano-SIFT-C", "autopano-sift-c", "--maxmatches %p %o %s"

(Unfortunately unless you are using an SVN snapshot of
autopano-sift-C, this last one chokes on input filenames containing
spaces)

There is the autopano-noop.sh script which ships with Hugin, this
gives a nice warning if autopano-sift-c isn't installed (recommended
for linux distributions that can't ship SIFT):

"Autopano NOOP", "autopano-noop.sh", "--maxmatches %p --projection %f,%v %o %i"

There is match-n-shift, a Panotools::Script wrapper around
autopano-sift-C, this is slow but the advantage is that it
incorporates ptoclean, this would look like this:

"Match'n'Shift", "match-n-shift", "-b -a -f %f -v %v -c -p %p -o %o %i"

There is Pan-o-matic which is also useful, the config looks like
this:

"Pan-o-matic", "panomatic", "-o %o %i"

Finally there is align_image_stack which is no good for general
alignment of panoramas, but can be used to generate control points
for photos within a single stack for which it is very good:

"Align image stack", "align_image_stack", "-f %v -p %o %i"

Actually, something like this ought to work better (untested):

"Align image stack", "align_image_stack", "-f %v `[ %f == 2 ] || [ %f == 3 ] && echo -n ' -e'` -p %o %i"

I'm not sure why I started this, I guess some of these should be
added as preset alternatives to the hugin control point preferences.

Opinions?

--
Bruno

[Dale Beams]

After working with both autopoint-sift-c and matchpoint, i'm finding that panomatic is finding the best points.

Dale

> Date: Sun, 6 Sep 2009 23:17:42 +0100
> From: br...@postle.net
> To: hugi...@googlegroups.com
> Subject: [hugin-ptx] Control point generator incantations

[Yuv]

the more the merrier! I would suggest giving more meaningful names
(first column) indicating the purpose of the settings. Some works
better with fisheye lenses than others.

Also we still lack the one holy grail of no-patents detector.
panomatic uses SURF; autopano uses SIFT and Fedora and Debian do not
distribute any of them because of the patents.

Yuv

[Bart van Andel]

On 7 sep, 05:26, Yuv <goo...@levy.ch> wrote:
> the more the merrier! I would suggest giving more meaningful names
> (first column) indicating the purpose of the settings. Some works
> better with fisheye lenses than others.

I haven't even checked out this new preset thing (which I deem a very
good idea!), so I don't know if I'm saying something stupid, but
wouldn't a comment or description field be a better solution to
describe the purpose of each preset? I'd favour this over using very
long names.

--
Bart

[Yuval Levy]

an *additional* comment / description may or may not be useful - the
defaults can also be explained in the manual.

What we absolutely need is a way to identify the different settings, and
this goes via *short* descriptive name.

The idea is that users give names that are meaningful to them; but we do
need to name the defaults properly.

Right now I can define three different Autopano-SIFT-C settings and give
all three of them the same "Autopano-SIFT-C" name. The preferences panel
does not complain. This will generates confusion later on, e.g. in the
Images tab where I have a drop down with three entries that look exactly
the same. Even "Autopano-SIFT-C 1","Autopano-SIFT-C 2","Autopano-SIFT-C
3" would be better than the present situation.

This is, of course, just for defaults. It is expected that the user will
give those settings a meaningful name, e.g. I already see myself giving
them names such as "8mm full spherical" or "rectilinear gigapano" to
relate them with my own workflow.

It would also make sense to add the "Points per Overlap" (currently in
the Images tab) to the settings. When I work with my calibrated fisheye
lens, I often use only 4 CPs per overlap. On the other hand, there are
situations when I like to generate more CPs.

Ultimately we need a short, descriptive, custom name for the user to
recognize their own settings; and to identify the defaults that will be
shipped with Hugin.

Yuv

[Bruno Postle]

On Mon 07-Sep-2009 at 13:00 -0400, Yuval Levy wrote:
>
>What we absolutely need is a way to identify the different settings, and
>this goes via *short* descriptive name.

Long descriptions need support for translation and this effort
should go into creating a properly working patent-free control point
generator rather than giving the user a choice between part-working
alternatives.

For now I think we should just ship these presets:

1. autopano-sift-c (default)
2. panomatic
3. match-n-shift (not on windows)
4. autopano.exe (only on windows)
5. align_image_stack

I'm tempted to switch autopano-sift-c with autopano-noop.sh on Linux
as they are functionally identical - Currently I patch this in when
packaging for fedora.

--
Bruno

[Yuval Levy]

Bruno Postle wrote:
> On Mon 07-Sep-2009 at 13:00 -0400, Yuval Levy wrote:
>> What we absolutely need is a way to identify the different settings, and
>> this goes via *short* descriptive name.
>
> Long descriptions need support for translation

The long descriptions are not my point.

My point is that there can be multiple settings for the same tool and
that currently the short description allows one to have the same short
name more than once. This affects also the potential patent-free cp
generator.

> For now I think we should just ship these presets:
>
> 1. autopano-sift-c (default)
> 2. panomatic
> 3. match-n-shift (not on windows)
> 4. autopano.exe (only on windows)
> 5. align_image_stack

why match-n-shift not on windows? IIRC it was working?

> I'm tempted to switch autopano-sift-c with autopano-noop.sh on Linux
> as they are functionally identical - Currently I patch this in when
> packaging for fedora.

I second this. Default should be autopano-noop.sh (or the Windows
equivalent) so that also users of distributions that don't have a CP
generator get a meaningful feedback (which can be a statement telling
them to install a CP detector and change the preference).

Yuv (waiting for his trunk to build with the pano12 cruft removed before
filing a patch)

>

[Bruno Postle]

On Mon 07-Sep-2009 at 17:48 -0400, Yuval Levy wrote:
>
>My point is that there can be multiple settings for the same tool and
>that currently the short description allows one to have the same short
>name more than once. This affects also the potential patent-free cp
>generator.

I don't think there is any need to ship with alternative
incantations for each tool, I just included all variations in the
email as this stuff needs to be documented somewhere.

There is really only one sensible set of parameters for each, I'll
commit the autopano-sift-c --projection parameter anyway as this has
been supported since 2.5.0 over a year ago.

>> For now I think we should just ship these presets:
>>
>> 1. autopano-sift-c (default)
>> 2. panomatic
>> 3. match-n-shift (not on windows)
>> 4. autopano.exe (only on windows)
>> 5. align_image_stack
>
>why match-n-shift not on windows? IIRC it was working?

Apparently the binaries I produced didn't have all the right perl
modules, it will work, but somebody else needs to do it.

>> I'm tempted to switch autopano-sift-c with autopano-noop.sh on Linux
>> as they are functionally identical - Currently I patch this in when
>> packaging for fedora.
>
>I second this. Default should be autopano-noop.sh (or the Windows
>equivalent) so that also users of distributions that don't have a CP
>generator get a meaningful feedback (which can be a statement telling
>them to install a CP detector and change the preference).

Actually autopano-noop.sh in 2009.2.0 tests for autopano-sift-c and
just passes through the command if it is present. i.e. it _should_
be a painless default on Linux/unix.

--
Bruno

[Yuval Levy]

Bruno Postle wrote:
> I don't think there is any need to ship with alternative
> incantations for each tool,

it's not about "shipping with" alternatives. It is about making sure
that the name given to a further incantation added by the user is unique
(i.e. check that it is not an already existing name)

>> why match-n-shift not on windows? IIRC it was working?
>
> Apparently the binaries I produced didn't have all the right perl
> modules, it will work, but somebody else needs to do it.

The instructions are at
<http://panospace.wordpress.com/2008/06/25/perl-in-windows/>

Yuv

[RueiKe]

Hi Bruno,

Not sure if I found a bug or if I am doing something wrong. I am
using SVN4352 of 2009.2. I attempted to use the default arguments for
autopano-SIFT-C, and I found that it indicates conversion to a
stereographic projection in the control point generation window, even
though an equirectangular projection is indicated in both the stitcher
tab and quick preview window. It only finds 3 control points. When I
remove the "--projection %f,%v" option it finds over 500 control
points.

Regards,
Rick

[Bruno Postle]

On Sat 12-Sep-2009 at 07:38 -0700, RueiKe wrote:
>
>Not sure if I found a bug or if I am doing something wrong. I am
>using SVN4352 of 2009.2. I attempted to use the default arguments for
>autopano-SIFT-C, and I found that it indicates conversion to a
>stereographic projection in the control point generation window, even
>though an equirectangular projection is indicated in both the stitcher
>tab and quick preview window. It only finds 3 control points. When I
>remove the "--projection %f,%v" option it finds over 500 control
>points.

The stereographic conversion is used for input images, the
projection of the output shouldn't make any difference to
control-point detection.

I suspect that the initial field of view or projection of your
photos is being misread. Are you entering values manually when you
load the photos? or is hugin estimating them from the EXIF info?

i.e. what values are set in the Camera and Lens tab immediately
before generating control points?

--
Bruno

[RueiKe]

Hi Bruno,

Hugin is able to estimate them from the EXIF data. The values
immediately after loading are Normal (rectilinear), degrees of
view=84.00737, focal length=20, crop factor=1.

Here is text while processing one of the images:

Filename K:\HWD\RL3_8447.tif
rectilinear width 4256 height 2832 hfov 180
reduce to 1600 x 1064 (Scale 2.6600)...
convert to stereographic projection ...
find keypoints ...
69 keypoints found

For this set of images, it finds a bit more points, but all of them
are in very near the center of each image and much less than without
the projection specified.

Regards,
Rick

[Bruno Postle]

On Mon 14-Sep-2009 at 06:27 -0700, RueiKe wrote:
>
>Hugin is able to estimate them from the EXIF data. The values
>immediately after loading are Normal (rectilinear), degrees of
>view=84.00737, focal length=20, crop factor=1.
>
>Here is text while processing one of the images:
>
>Filename K:\HWD\RL3_8447.tif
> rectilinear width 4256 height 2832 hfov 180

You found a bug, basically the autopano-sift-c --projection option
doesn't work in the current trunk, it always assumes an angle of
view of 180:

Current trunk:
./autopano-sift-c --projection 0,84 new.pto /tmp/RL3_844*
...

rectilinear width 4256 height 2832 hfov 180

2.5.0:
autopano-sift-c --projection 0,84 new.pto /tmp/RL3_844*
...
width 4256 height 2832 format 0 hfov 84

This appears to have broken with svn4082.

Note to packagers, the current stable version of autopano-sift-C is
2.5.0, this version does have a substantial memory leak which is
fixed in svn3895 - Any snapshot after this should be considered
unstable.

--
Bruno