Problems stitching with newer versions of Hugin

[Greg 'groggy' Lehey]

I've been making documentary panoramas of my house every week for the
past 10 years, and for a long time I was using version 2018.0.0 of
hugin on an old machine that I didn't plan to upgrade, running FreeBSD
10.2. I now have a new machine running FreeBSD 13.2 and Hugin version
2023.0.0.d88dc56ded0e, but I'm having problems stitching panoramas
that work without problem with the old version. I have a diary
article on the subject at
http://www.lemis.com/grog/diary-may2024.php?subtitle=More%20Hugin%20strangenesses&article=D-20240506-014938#D-20240506-014938,
which shows the images and includes a link to the pto file used for
both images. I haven't uploaded the component images, since they're
nearly 1 GB in size, but if anybody is interested, I can do so.

In more detail: The panorama was taken with an Olympus OM-D E-M1 Mark
II and an M.Zuiko 8 mm f/1.8 fisheye. Each view was an HDR composite
of 3 images taken at 3 EV intervals. The invocation was

hugin_executor --stitching laundry-door.pto

The defective view shows a hole where one of the images was masked,
and a large smudge in the middle, which may be due to the fact that
the images in question were taken out of sequence. I have had quite a
number of such problems with other panoramas: this isn't an isolated
case, and it's stopping me from upgrading.

Greg
--
Sent from my desktop computer.
Finger gr...@lemis.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.php

[wirz]

Hi Greg,

What version of enblend are you using? While I don't know what differs
between the versions of hugin / enblend that are packaged in freeBSD,
your images very much look like the old enblend bug that was fixed
recently (earlier this year). If your enblend is older than mid
February 2024 / changeset 1556, I'd recommend to try a newer version.
If, on the other hand, your enblend is newer than that I would be very
interested in those images to reproduce the problem.

cheers, lukas wirz

[Greg 'groggy' Lehey]

On Monday, 6 May 2024 at 15:58:31 +0000, wirz wrote:
> On 06/05/2024 06:05, Greg 'groggy' Lehey wrote:
>> I've been making documentary panoramas of my house every week for the
>> past 10 years, and for a long time I was using version 2018.0.0 of
>> hugin on an old machine that I didn't plan to upgrade, running FreeBSD
>> 10.2. I now have a new machine running FreeBSD 13.2 and Hugin version
>> 2023.0.0.d88dc56ded0e, but I'm having problems stitching panoramas
>

> What version of enblend are you using?

The version currently available at http://enblend.sourceforge.net/,
which identifies itself as 4.2. But all the files are much older than
this year.

> While I don't know what differs between the versions of hugin /
> enblend that are packaged in freeBSD, your images very much look
> like the old enblend bug that was fixed recently (earlier this
> year). If your enblend is older than mid February 2024 / changeset
> 1556, I'd recommend to try a newer version.

Yes, that sounds like a good idea. Only: where do I find this
version? Am I wrong in looking at http://enblend.sourceforge.net/?

[wirz]

On 07/05/2024 10:19, Greg 'groggy' Lehey wrote:
> On Monday, 6 May 2024 at 15:58:31 +0000, wirz wrote:
>> On 06/05/2024 06:05, Greg 'groggy' Lehey wrote:
>>> I've been making documentary panoramas of my house every week for the
>>> past 10 years, and for a long time I was using version 2018.0.0 of
>>> hugin on an old machine that I didn't plan to upgrade, running FreeBSD
>>> 10.2. I now have a new machine running FreeBSD 13.2 and Hugin version
>>> 2023.0.0.d88dc56ded0e, but I'm having problems stitching panoramas
>>
>> What version of enblend are you using?
>
> The version currently available at http://enblend.sourceforge.net/,
> which identifies itself as 4.2. But all the files are much older than
> this year.

That's slightly old, the version has been 4.3 for a bit.

>> While I don't know what differs between the versions of hugin /
>> enblend that are packaged in freeBSD, your images very much look
>> like the old enblend bug that was fixed recently (earlier this
>> year). If your enblend is older than mid February 2024 / changeset
>> 1556, I'd recommend to try a newer version.
>
> Yes, that sounds like a good idea. Only: where do I find this
> version? Am I wrong in looking at http://enblend.sourceforge.net/?

That's the right place, can get the current source here:
https://sourceforge.net/p/enblend/code/ci/default/tree/

cheers, lukas wirz

[T. Modes]

lukas wirz schrieb am Dienstag, 7. Mai 2024 um 18:20:03 UTC+2:

That's slightly old, the version has been 4.3 for a bit.

Just to make it more clear. The last released version is 4.2.

The current development in the default branch of the repository is using the version 4.3 to identify. This will be the next released version.

Lukas changes are currently only in the default branch of enblend repository http://hg.code.sf.net/p/enblend/code

but not in any official released version.

[wirz]

On 07/05/2024 21:59, 'T. Modes' via hugin and other free panoramic

Yes, sorry, I was ignoring the difference between internally named
versions and released versions.

[Greg 'groggy' Lehey]

OK, done that. It would be good if the README file included more
detailed build instructions. It starts by running ./configure, which
is built in the first stages of install, and it took me a while to
find out how to build things. I can't use the FreeBSD framework
because it would require significant changes.

I could suggest changes, but I don't know how they would affect
Microsoft and Apple.

So: I've tried things out, specifically enblend 4.3-e87da60fab22.
It's better, but not good. I've put comparison images at

http://www.lemis.com/grog/photos/Photos.php?dirdate=20240511&imagesizes=01110000000000000000000000

Click to enlarge. They show the output from enblend 4.1.4, 4.2 and
4.3 respectively. As you can see, 4.3 is better than 4.2, but not as
good as 4.1.4. I've also put the build logs at

http://www.lemis.com/grog/Day/20240511/Log-enblend-4.1.4
http://www.lemis.com/grog/Day/20240511/Log-enblend-4.2
http://www.lemis.com/grog/Day/20240511/Log-enblend-4.3

Let me know if you want the source images (a total of 683 MB). For
some reason this particular view frequently suffers from this problem.
At one point I thought that this was masking, but there are no masks
today. And the images were taken starting roughly in the middle of
the view.

[wirz]

Hi Greg,

[I'm switching back to the main list as it might be relevant for other
folks.]

On 22/06/2024 08:55, Greg 'groggy' Lehey wrote:
> On Friday, 21 June 2024 at 22:56:06 +0000, wirz wrote:
>> Hi Greg,

>>
>>> So: I've tried things out, specifically enblend 4.3-e87da60fab22.
>>> It's better, but not good. I've put comparison images at
>>>
>>> http://www.lemis.com/grog/photos/Photos.php?dirdate=20240511&imagesizes=01110000000000000000000000
>>>
>>> Click to enlarge. They show the output from enblend 4.1.4, 4.2 and
>>> 4.3 respectively. As you can see, 4.3 is better than 4.2, but not as
>>> good as 4.1.4. I've also put the build logs at
>>>
>>> http://www.lemis.com/grog/Day/20240511/Log-enblend-4.1.4
>>> http://www.lemis.com/grog/Day/20240511/Log-enblend-4.2
>>> http://www.lemis.com/grog/Day/20240511/Log-enblend-4.3
>>>
>>> Let me know if you want the source images (a total of 683 MB). For
>>> some reason this particular view frequently suffers from this problem.
>>> At one point I thought that this was masking, but there are no masks
>>> today. And the images were taken starting roughly in the middle of
>>> the view.
>>

>> Could you make the set of images and the pto-file available to download
>> somewhere? Looking at your blog, I see that you had a different example a
>> day later, which has several artefacts from the tripod included. That might
>> be even more interesting to look at instead.

[...]

> Let me know when you have the file and I'll remove it again. If this
> isn't the set that you're looking for, let me know which you want.

I've looked at the example case for a while, trying to answer three
questions: a) What about those dark (nb, not black!) corners? b) Where
do the large slightly too bright areas come from? c) What is different
from version 4.1.4?

a) This is simple, they are parts of the tripod, but you know that of
course. While they are not desirable, I wouldn't call it a bug if some
corners of an actual image end up in the blended result. Using masks is
the only way to be sure.

b) These are generated whenever the seamline lies on or very close to
the overlapping area of two images that get blended. The mechanism is,
that on one side of the seamline, even very close to the seam line there
are no contributions available from the other image. In other words, on
one side of the seamline we get a blended result while on the other side
we just get the unblended input image. Given such a seamline, this
can't be fixed. The question needs to be how to not get such a seamline.
Enblend has two algorithms for generating primary seamlines:
nearest-feature-transform and graph-cut. While graph-cut is more
sophisticated and produces better details, it can sometimes be
completely wrong (such as unnecessary loops around half the image,
something that looks like self intersections, and seamlines that get
shifted to the boundary of the overlap areas). My general advice would
be to use graphcut, and if weird things happen, use NFT. Indeed I get
perfect results if I use NFT for your test case, while there are some
truly insane seamlines produced by GC.

c) Version 4.1.4 was released ~9 years ago and I don't manage to
compile it without installing old versions of boost and old compilers.
So I didn't.

cheers, lukas wirz

[Greg 'groggy' Lehey]

On Saturday, 22 June 2024 at 20:02:27 +0000, wirz wrote:
>
> I've looked at the example case for a while, trying to answer three
> questions: a) What about those dark (nb, not black!) corners? b) Where do
> the large slightly too bright areas come from? c) What is different from
> version 4.1.4?
>
> a) This is simple, they are parts of the tripod, but you know that of
> course. While they are not desirable, I wouldn't call it a bug if some
> corners of an actual image end up in the blended result. Using masks is the
> only way to be sure.

Another way is to use enblend 4.1.4. Yes, masking them out would
work, but it's a lot of work. I've never had issues with enblend
4.1.4.

> b) ... Enblend has two algorithms for generating primary seamlines:

> nearest-feature-transform and graph-cut. While graph-cut is more
> sophisticated and produces better details, it can sometimes be
> completely wrong (such as unnecessary loops around half the image,
> something that looks like self intersections, and seamlines that get
> shifted to the boundary of the overlap areas). My general advice
> would be to use graphcut, and if weird things happen, use NFT.
> Indeed I get perfect results if I use NFT for your test case, while
> there are some truly insane seamlines produced by GC.

I went looking for the enblend man page, but drew a blank. All I have
is the --help. You're talking about one of these, right?

--primary-seam-generator=graph-cut
--primary-seam-generator=nearest-feature-transform

I may try this. Is it possible to have a less verbose variant?

> c) Version 4.1.4 was released ~9 years ago and I don't manage to
> compile it without installing old versions of boost and old
> compilers. So I didn't.

Yes, I had difficulty there too. But it looks as if it might be worth
it. None of these issues has shown up with 4.1.4. What was wrong
in that version that required changes in the algorithm?