I think all three should be fixed. #3 was one motivation for writing Multiblend, because it can cause problems even when seams don't stray (particularly when image edges make a corner). Multiblend assumes any out-of-bounds pixel (per image) is the same colour as its nearest in-bounds neighbour.
Of course even if you do that, if seam lines stray too close to the overlap then you will end up using the higher frequency components of those "fake" pixels to fill in that black hole, which is also not ideal, and if the seam lines stray *outside* the overlap region then you get those "fake" pixels directly visible (black in Enblend's case because it doesn't extend images in that way). NFT seams should never go near the edges, so if it happens without optimisation I assume it's down to using a coarse mask. My knowledge may be a bit out of date, but my understanding of Enblend's seam generation is that the NFT is very precise (geometrically speaking) but very slow (hence the option for coarse masks), and the precision is unwarranted given that there are much faster methods and geometric precision isn't necessary. Multiblend's seams are different, but for practical purposes they are just as valid as Enblend's. I've been doing a lot of work on image pyramids lately so a new version of MultiBlend may be a future project. I just did a test with a 70mp 11 image mosaic and MultiBlend is still 25x faster than the latest Enblend (with like-for-like settings) :D I know a lot more about multithreading and SSE now, so I'm hoping for at least double the speed. On Wednesday, 25 September 2019 22:14:41 UTC+1, lukas wrote: > > Hi, > > I have a been looking at the enblend problem that is described here > (https://bugs.launchpad.net/enblend/+bug/721136) a bit more. > > In all examples that I know of, the problem is that the seamline(s) > run(s) slightly outside of the overlap area. 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. > > An obvious example is the result (1) with seamlines (2) which is > generated from the example files I have added to the above thread. This > particular example uses coarse/no-opt/gc. > > > 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 > 2) the seamline optimisation should return only seams inside the > overlapping region > 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. > > > 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)? > > cheers, lukas > > > (1) http://78.46.190.157:8080/foo.tif > (2) http://78.46.190.157:8080/vis-1.tif > > -- 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/e611fb9f-7179-4aaf-9d87-bb3e6204edee%40googlegroups.com.
