A possibility that often is overlooked is the reason for many glitches in modern computer games: What if all algorithms work out as expected - but even the small numeric error double floats make add up to one pixel? Wilkinson's polynomial shows us that truly catastrophic add-up can occur in simple mathematical problems of the like hugin solves even without trigonometric functions that can convert small errors on the input to large errors on the output => leaving one pixel of error margin might do wonders even where the equation is flawless math. If Wilkinson's polynomial isn't impressive enough feel free to search for Siegfried Rump's polynomials. Both have been indicated to me by Richard Fateman from the maxima Project that is about an open-source program that is willing willing to do nearly all maths (including playing with equations) you'll ever need.
Kind regards, Gunter. Am 4. November 2019 20:02:45 MEZ schrieb Wirz <[email protected]>: >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 [email protected]. >To view this discussion on the web visit >https://groups.google.com/d/msgid/hugin-ptx/d5a0e390-1a9d-2bc8-c134-c4e23401dbec%40lukas-wirz.de. -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. -- 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/14AD78CD-7287-473C-834D-606F74D5E48B%40gmail.com.
