arbitrary stop errors because of excessive overlap

[Erik Krause]

Sometimes enblend stops with error code 1 and a message "excessive overlap detected; remove one of the images". This behavior is arbitrary. F.e. a test project with 8 images all in the exact same place on an equirectangular canvas doesn't cause the error. The message is probably related to http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/rev/5c2c0a81fcb3

enblend versions prior to 4.0 used to warn on redundant images and in fact version 4.0 still does f.e in case of the above mentioned project with 8 images.

[Bruno Postle (brunopostle)]

I agree, I would rather see either:

1. discard the redundant image
2. attempt to blend the images anyway with a warning

The current situation results in a lot of user frustration. It would be better for them to see bad results than have no result at all after (potentially) hours of processing.

[schu-r (schu-r-users)]

I make HDR Panoramas with about 100 Images. Which takes a while to Calculate.
It is frunstrating to see two Hours later taht enblend has stopped wokring, because of a 'safety' Picture (one I took to make sure I got the whole 360° Panorma)

Please just make a Warning!!!!!

[Yuv (yuv)]

it is not possible to "just make a warning". when this error happens it is because the algorithm can't solve the problem.

that said, there could be a better way than frustrating the user with an error message and no result after hours of crunching.

to my understanding, enblend adds one image at the time. how about adding a switch to keep the previous results?

example:

images: [1,2,3,4,5]

blend 1 and 2 => success. save 1+2 as temp result.
blend 1+2 and 3 => success. save 1+2+3 as temp result and discard 1+2.
blend 1+2+3 and 4 => error. fail, but leave 1+2+3 on the user HDD.

this leave the user with the option of either blend 1+2+3 and 5 or (as today), remove image 4 from the set and start from scratch with bending [1,2,3,5]

[Erik Krause (erik-krause)]

As written in the bug description enblend versions prior to 4.0 didn't show the problem. And http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/rev/5c2c0a81fcb3 tells that the questionable behavior most likely was introduced deliberately (in order to prevent users from confusing enblend with enfuse).

The heading of the above mentioned page says "Prevent enblending of the same image". Since enblend could detect and handle redundant images before (and did it more reliably than the new code) I see no need to have this code at all.

[Yuv (yuv)]

versions prior to 4.0 had a completely different algorithm. If there was one mistake in the move from 3.x to 4.x, it was that the 4.x algorithm *replaced* the 3.x algorithm instead of complementing it (with an option to choose which one to run).

the current GSoC project on Enblend is adding modularity to enable multiple seam placement algorithms under the same code base. It will bring a new challenge (how to determine which one of the multiple choices of seams is the best one?) that is already being thought of. Maybe it is also an opportunity to resurrect the old 3.x algorithm as one of the many options - one that is obviously superior in the cases that trigger this error.

as for the deliberate nature of the "questionable" behavior, have you tried to change the arbitrary threshold and see what happens? the changeset linked in comment #4 is very well documented. set overlap_threshold to 0 and run a test case against a recompiled version of enblend. please report interesting results here.

[Erik Krause (erik-krause)]

This might or might not be true, I can't judge. However, the comment to patch http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/rev/5c2c0a81fcb3 says: "Prevent enblending of the "same" image. Sometimes a user tries to feed images to Enblend that are meant to be the input to Enfuse." Christoph Spiel emphasized this same reason in a personal mail to me. All this doesn't sound as if the algorithm required the change.

To summarize:
- The mentioned error message does not appear in any case it should appear as shown in a test case.
- Enblend runs on 100% overlapping images without troubles.
- Stopping the program without output is a major annoyance at this stage of processing.

I think this are enough reasons to raise the importance from "wishlist" to medium or even high, especially since the fix looks easy: simply remove the above mentioned patch.

[makc (makc-the-great)]

I came to enblend tracker looking if there's anything I could do about https://bugs.launchpad.net/hugin/+bug/696949 except for waiting the response (as I kind of want my pano stitched) and I have to say I share same sentiments. How can possibly hurt to add extra overlapping images? When you do the same by hand in photoshop, it only helps by averaging the noise out, and results in nicer image, no?

[Tristan Burtenshaw (tburtenshaw)]

I think it should be fixed too.

Was it only added to stop people confusing enblend and enfuse??
http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/rev/5c2c0a81fcb3

[Kim Bruning (e9x6-kim)]

This breaks for me too (though I can find some workarounds). In my case it's very hard to fix: I'm making a quick pan shot with my camera, converting to jpg with ffmpeg, and then trying to blend. This *SHOULD* work, right? :-)

[simpsus (bastian-kennel)]

The usage of Hugin breaking because of this is simply not acceptable.
In the Hugin FAQ (http://wiki.panotools.org/Hugin_FAQ#enblend:_excessive_overlap_detected) there are several workarounds mentioned:

1) Remove the image: No.
2) Switch back to enblend 3.2: How do I do that? Enblend 3.2 worked very well for me. Is there a .deb or could someone point out how to do this? Doesn't the neblend package depend on enblend 4.0?
3) Select "Exposure Fusion" in the stitcher tab. There is no such entry. There are exposure related output options, but none of them change the behaviour.
4) Mask a major portion of your image: I neither know what that means nor how it is done.

Could someone at least explain how to do 2 or 3 if the bug is not fixed at the source?

[Johannes Wienke (languitar)]

Is there any progress on this? With the 2013 version of Hugin I am completely unable to generate a HDR panorama from several bracketed images. ending in this error. I am not even sure whether this error might be correct and hugin lacks to correctly determine the image stacks?

[Patrick van der Leer (pat-vdleer)]

Any update???

[Erik Krause (erik-krause)]

Is this still not fixed?