Enblend treats larger input tif as black with --fine-mask

[Felix Hagemann]

Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if:
(a) --fine-mask is used, and
(b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok).

The attached images illustrate the problem: 2 input files (input0000.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well.

Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation was without OpenMP, trying with or without imagecache does not make a difference.

[Yuv (yuv)]

On April 19, 2011 04:09:43 PM Felix Hagemann wrote:
> Blending two input tiff files (remapped files from hugin) with enblend
> results in one image treated as solid black during blending if: (a)
> --fine-mask is used, and
> (b) the input image size is large enough (here: 9000px high triggers the
> bug, 8000px and below is ok).

Thank you for the report. I had to upscale the images in the attached report
with ImageMagick convert -resize 9000x9000 and could not confirm with enblend
4.0-753b534c819d

the bug may have been introduced recently, I'll have to pull the recent
changes and try again.

[Yuv (yuv)]

On April 19, 2011 04:09:43 PM Felix Hagemann wrote:
> Blending two input tiff files (remapped files from hugin) with enblend
> results in one image treated as solid black during blending if: (a)
> --fine-mask is used, and
> (b) the input image size is large enough (here: 9000px high triggers the
> bug, 8000px and below is ok).

enblend 4.1-2f3c9caab556 with and without OpenMP on Kubuntu 11.04 can't
reproduce.

[Felix Hagemann (flixh)]

I could just reproduce the problem with
enblend 4.1-2f3c9caab556
and the attached original size files. I hope this 50MB attachment does make its way to launchpad.
Felix

[Felix Hagemann (flixh)]

I have just tried to reproduce on two beefier machines running a 64bit kernel. I cannot reproduce: neither with a freshly compiled version nor with the 4.0 in debian's repositories.
It's still failing on my main machine, though.

Any ideas?
Felix

[Yuv (yuv)]

what are the specs of the machine that produces the black areas?

I tested on a netbook class machine (core i3-380UM 4GB RAM).

[Felix Hagemann (flixh)]

> what are the specs of the machine that produces the black areas?

What was a very nice laptop back in 2004:
Pentium M 1.7 GHz with 2GB RAM. Enblend might run out of memory, but
shouldn't it fail/crash then instead of producing bogus output?
It's easy to see in this 2 image case, but when blending a spherical
pano and getting some strange grey/black smearing I was searching for
the reason for what felt like eternity... :-)

[Felix Hagemann (flixh)]

Today I have had that problem occur again processing a different image set. But this time it appeared on a 6 core i7 with roughly 6GB free RAM running a 64bit Linux.

So this is probably not a memory problem. Again the problem vanished when dropping "--fine-mask".

[Yuv (yuv)]

With the input images in comment #8 I can reproduce it on my netbook.

On the command line, Enblend outputs four times the following diagnostic message:

enblend: seam s-1 is a tiny closed contour and was removed after optimization

[Felix Hagemann (flixh)]

This problem has now appeared for me for a few different panoramas, independent of the use of "--fine-mask". Funny enough scaling the output images down has helped with one while with another one scaling up was avoiding the black spots.