black parts inside blend depending on final size

[Louis Strous]

Hugin "2018.0.0.5abfb4de7961 built by Thomas" on Windows 10.

I'm blending/fusing 21 images covering most of a scene at least twice, with exclusion masks on most of the images where another image covers the same part in a more desirable way. The resulting blended and blended_fused images looked OK (no black "holes" inside the final image) when I had the canvas width equal to 4000 px, but when I increased the canvas width to 8000 px (which automatically scaled the width of the final image as well) then two parts of the new blended_fused image corresponding to exclusion masks turned black, and one of those parts turned black in the new blended image as well. I tried several other canvas widths as well (5000 px, 7000 px, 7500 px, 7732 px, 7738 px, 7740 px, 7742 px) and all but one of those blended and blended_fused images show black parts corresponding to some exclusion masks, but not always the same ones. Three of the blended_fused images show a black area corresponding to one of the original images, with a very sharp left edge but with the right edge gradually fading to black. There is no obvious pattern to which parts turn black for which canvas width.

I have occasionally seen such unexpected black parts in blended and blended_fused images before, also with previous versions of hugin. I would then try using an older version of hugin (lately mostly the 2014 version) to stitch the project (without changing any parameters) and that often but not always produced good results. I hadn't before noticed that the canvas width had such influence.

I expected that the appearance of the final images with a smaller canvas width would be similar to the appearance of the final images with a larger canvas width, except for the reduction in resolution. I did not expect that there would be interior black parts for some canvas widths but not for others, even nearby others.

I attach the blended and blended_fused images at considerably reduced size, but still large enough that you can see where the unexpected black parts are. I also attach the project file, and the logs from two of the stitch operations. The file names begin with a number that is the canvas width. Here is the system information:

Operating System: Windows 10 (build 17134), 64-bit edition
Architecture: 64 bit
Free memory: 3649692 kiB
Active Codepage: 1252 (Western European Windows)

Hugin
Version: 2018.0.0.5abfb4de7961 built by Thomas
Path to resources: C:\Program Files\Hugin\share\hugin\xrc\
Path to data: C:\Program Files\Hugin\share\hugin\data\
Hugins camera and lens database: C:\Users\Louis\AppData\Roaming\hugin\camlens.db
Multi-threading using C++11 std::thread and OpenMP
Monitor profile: C:\WINDOWS\system32\spool\drivers\color\sRGB Color Space Profile.icm

Libraries
wxWidgets: wxWidgets 3.1.1
wxWidgets Library (wxMSW port)
Version 3.1.1 (Unicode: wchar_t, debug level: 1),
compiled at Nov 18 2017 10:28:15

Runtime version of toolkit used is 10.0.

libpano13: 2.9.19
Exiv2: 0.26
SQLite3: 3.18.0
Vigra: 1.11.0
LittleCMS2: 2.9

[tmodes (tmodes)]

This is a known bug in enblend. It is difficult to track down. see https://bugs.launchpad.net/enblend/+bug/721136
Workaround is to add switch --primary-seam-generator=nft to enblend options. Or using the internal blender.