Hi Thomas and Chris, Thank you for your suggestions! I'm not sure when I'll have time for that, but starting with improved error detection should certainly be doable for some time soon.
It's not important but I actually have an example where NFT+coarse+nopt leads to small but well visible black triangles next to the entry points of the seam. Even with NFT+fine+nopt I can spot a single black pixel. cheers, lukas On 30/10/2019 19:09, T. Modes wrote: > 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 hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/d5a0e390-1a9d-2bc8-c134-c4e23401dbec%40lukas-wirz.de.
signature.asc
Description: OpenPGP digital signature
