Hi Lukas,
I got an answer from Chris Spiel, the main enblend developer, to your
questions.
I hope this helps you further.
Am Mittwoch, 25. September 2019 23:14:41 UTC+2 schrieb lukas:
In all examples that I know of, the problem is that the seamline(s)
run(s) slightly outside of the overlap area.
Furthermore, there are problems if the Simulated-Annealing
seamline optimizer plaits loops or sometimes even only cusps.
As a result, pixels are
included from one image which lie outside the image's area, or in a
transparent area (which apparently is not invalid but black). This
problem can occur for NFT and GC, becomes less frequent with fine and/or
optimise but can occur with any combination.
I'd be surprised if **pure** NFT generates a seamline outside
the overlap area. BTW, you can compare the Vigra implementation
(default; on host CPU) with the OpenCL implementation of the NFT
running on a GPGPU (only Manhattan and Euclidean metrics here). Use
parameter "gpu-kernel-dt" to reroute the program flow.
Rosomack is the expert for GC; it's his code.
--- snip ---
If I understand the relevant algorithms correctly, this problem could
be/should be caught in three different places:
1) Neither GC nor NFT should return a seamline outside the overlap
Correct.
2) the seamline optimisation should return only seams inside the
overlapping region
Also correct.
3) the blending should not assume out-of-bound or transparent pixels to
be black but either transparent or take a pixel from the other picture.
Indeed we ought to file this item under "never reached". But
obviously these conditions **are** met and black or just weird areas can
show up in the blended image if the seamline took a detour to la-la
land.
Which brings me to my question: Do you have any opinion on where this
problem should be fixed? I would assume fixing 3) is the easiest and
safest. On the other hand, seamlines outside the overlap area, produced
by 1) or 2) entirely refute the point of finding a good seamline to
begin with (leading to poor quality). So maybe one should treat this
problem in all three places (four actually, because GC, NFT, opt, blending)?
After more than a decade of maintaining Enblend/Enfuse I can
tell you that the difficulties really start when you dive into the
code.
The first step I'd take is to add a set of precise diagnostics that
help spotting the problem. For example:
* issue a warning for any deviant seamline in the terminal window,
* improve the output of `--visualize',
* paint incorrect black areas with #ff00ff, or enclose them with
#00ffff-colored diamonds (at a minimum size to emphasize
single-pixel errors)
There is no reason to restrict these diagnostics to the final image as
any stage could be buggy and equally deserves a check. For
flexibility and reducing the number of recompilations `--parameter'
always comes in handy; see file "parameter.h".
IMO, the second step could be to work through the image-processing
pipeline front-to-back, i.e. start with the NFT, make it rock solid.
Then proceed to GC, harden it, and so on.
HTH,
cls
--
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/09274489-c781-44a8-9e33-d7c42d4fc6f1%40googlegroups.com.
