Hi! On 26/09/2019 20:27, Monkey wrote: > 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.
That's a good points, I hadn't thought about the diffuser blending layers. > 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 you mean lower frequency, right? > 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). Do you know how many pixels are maximally included to both sides (by means of diffuser layers) in enblend and multiblend? I have never noticed an artefact where there is a grey fringe without black which should result from the seam being close to the edge but not beyond the edge. > 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. NFT is of course very close to the edge at the two entry points and if either the coarse mask or the optimisation mess up, it might end up on the wrong side ... > Multiblend's seams are different, but for practical purposes they are just > as valid as Enblend's. Is there an easy description of how they are constructed? Do you explicitly penalise close proximity to the edges? cheers, lukas > 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 hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/503164a5-a839-21c6-022e-901ab47eb895%40lukas-wirz.de.
signature.asc
Description: OpenPGP digital signature
