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
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/2c6b2ee8-842f-4352-83b6-dcfe57cac8f3%40posteo.net.
