Best Linux distro for Hugin?

[Greg 'groggy' Lehey]

I've been having a strange issue with Hugin for some time now, and
I've traced it to a difference between the Microsoft and FreeBSD
versions. On the FreeBSD version, the control point detectors find no
control points at all between the first and last images of a circular
panorama. There's no obvious reason for this, and it seems that
"first" and "last" refer to the order in which the images are loaded.

I'm still trying to understand this, but an obvious thing to do would
be to try it on Linux and see what happens there. Which distro should
I use?

If anybody wants to play with the images, I have low-quality versions
which show the effect at
http://www.lemis.com/grog/Day/20180602/e-from-house.tar (about 14 MB),
or, if you don't do tar,
http://www.lemis.com/grog/Day/20180602/e-from-house-0.jpeg,
http://www.lemis.com/grog/Day/20180602/e-from-house-2.jpeg,
http://www.lemis.com/grog/Day/20180602/e-from-house-3.jpeg and
http://www.lemis.com/grog/Day/20180602/e-from-house-4.jpeg. I have
also included my .hugin file at
http://www.lemis.com/grog/Day/20180602/.hugin, and it's in the
tarball. There's no
http://www.lemis.com/grog/Day/20180602/e-from-house-1.jpeg, which
isn't needed here. The photos were taken with a full-frame fisheye,
and Exif data is complete.

Apart from this, can anybody think of another reason why this might
happen? I've checked the .hugin file but found nothing obvious.

Greg
--
Sent from my desktop computer.
Finger groo...@gmail.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[Bruno Postle]

The control point detectors are configurable in the Hugin preferences. It sounds like you have cpfind --linearmatch set.

Unless you need customised control point detectors, I would reset everything using the load defaults button.

--
Bruno

[Gunter Königsmann]

Also cpfind will fail if you have once set up the lens parameters wrong by a big enough factor once and hugin remembers that lens and your parameters.

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/830C769A-8095-4C74-A8E5-DA92EB3A3758%40postle.net.
For more options, visit https://groups.google.com/d/optout.

[Greg 'groggy' Lehey]

On Monday, 4 June 2018 at 11:18:13 +0100, Bruno Postle wrote:
> On 4 June 2018 03:30:17 BST, Greg 'groggy' Lehey wrote:
>> I've been having a strange issue with Hugin for some time now, and
>> I've traced it to a difference between the Microsoft and FreeBSD
>> versions. On the FreeBSD version, the control point detectors find no
>> control points at all between the first and last images of a circular
>> panorama. There's no obvious reason for this, and it seems that
>> "first" and "last" refer to the order in which the images are loaded.
>

> The control point detectors are configurable in the Hugin
> preferences. It sounds like you have cpfind --linearmatch set.

Possibly, but that wasn't the case. I did have --multirow, but that's
all. Also, which I forgot to mention in my initial email, I had moved
~/.hugin out of the way, so hugin created a new, default one. In each
case, it runs as:

grog 9754 30.0 0.6 350888 216912 - Rs 9:56am 0:02.02 cpfind --multirow -o /tmp/ap_resopKKTn /tmp/ap_inprojtMDmqp
grog 9753 11.8 0.3 419500 85784 - Ss 9:56am 0:00.25 /usr/local/bin/icpfind -o /tmp/halB5Z5x /tmp/halB5Z5x

Also I have done this both with panomatic and cpfind, and both show
the same effect. So whatever it is, it's not that.

[Greg 'groggy' Lehey]

On Monday, 4 June 2018 at 18:37:36 +0200, Gunter Königsmann wrote:
> Also cpfind will fail if you have once set up the lens parameters wrong by
> a big enough factor once and hugin remembers that lens and your parameters.

Yes, I've run into that, especially as in this case I was using a
fisheye lens. But it's very much just the overlap at the end. If I
load the first image a second time at the end, both cpfind and
panomatic find control points with the second copy, but not the first.

[Greg 'groggy' Lehey]

On Monday, 4 June 2018 at 12:30:17 +1000, Greg 'groggy' Lehey wrote:
> I've been having a strange issue with Hugin for some time now, and
> I've traced it to a difference between the Microsoft and FreeBSD
> versions. On the FreeBSD version, the control point detectors find no
> control points at all between the first and last images of a circular
> panorama. There's no obvious reason for this, and it seems that
> "first" and "last" refer to the order in which the images are loaded.

On Monday, 4 June 2018 at 11:18:13 +0100, Bruno Postle wrote:

> The control point detectors are configurable in the Hugin
> preferences. It sounds like you have cpfind --linearmatch set.
>
> Unless you need customised control point detectors, I would reset
> everything using the load defaults button.

I've spent some time investigating this, and discovered:

1. Yes, --linearmatch only matches the previous and next image in the
stack.
2. So does --multirow!
3. This has nothing to do with FreeBSD. My Microsoft version
(latest, downloaded from the web site) does exactly the same
thing.

I've done a bit of looking through the code, but without internals
documentation it's a bit hard to understand. I've established that
this behaviour occurs at least as far back as 2013 versions (again,
Microsoft, to avoid any misunderstandings).

So: is this intentional? In that case, it should be documented. Or
is it accidental? In that case it should, of course, be fixed. And
looking at the documentation, how important is the option any more?

[T. Modes]

Am Mittwoch, 20. Juni 2018 06:03:31 UTC+2 schrieb Groogle:

I've spent some time investigating this, and discovered:

1.  Yes, --linearmatch only matches the previous and next image in the
    stack.
2.  So does --multirow!

Yes, linear match is the first step of multi row. But you missed that multirow does more after it.

With linear match you should see something like

--- Find pair-wise matches ---
i0 <> i1 : Found 21 matches
i1 <> i2 : Found 21 matches
i2 <> i3 : Found 23 matches

But with multi row you should see something like

--- Find matches ---
i0 <> i1 : Kept 22 matches.
i1 <> i2 : Kept 23 matches.
i2 <> i3 : Kept 21 matches.

--- Find matches for overlapping images ---
i0 <> i2 : Found 0 matches.
i1 <> i3 : Found 0 matches.

(or alternatively the last section empty)

The main cause why cpfind does not connect the first and last image in this example is the wrong fov. (So the overlap can't calculated correctly and therefore it is not checked for cp's in the mentioned image pair).

And the fov is not correctly updated after reading the lens projection from the lens database. (This happens only for non rectilinear images, e.g. fisheye lenses).

I fixed this in the repository in the default branch.

Now cpfind should print now something like:

--- Find matches ---
i0 <> i1 : Kept 22 matches.
i1 <> i2 : Kept 21 matches.
i2 <> i3 : Kept 25 matches.

--- Find matches for overlapping images ---
i0 <> i3 : Kept 21 matches.