hugin-devs team mailing list archive

[rew <685898@xxxxxxxxxxxxxxxxxx>]

This doesn't happen with current enblend 4.0. I stitched your sample
files in both orders and got very similar results.

If it happens again, can you check wether you have imagecache compiled
in? If it is compiled enblend accepts the -m option. (otherwise it
doesn't).

I have seen corruption where enblend would think that black pixels
existed where only alpha=0 pixels were present....

** Changed in: enblend
       Status: New => Fix Released

** Changed in: enblend
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/685898

Title:
  Difference between input and output in non-overlap regions

Status in Enblend:
  Fix Released

Bug description:
  Say, we have two images that have a common overlap in a vertical region in the middle, and no common pixels on the left and right sides, where alpha and rgb values are set to 0. For certain image sizes and content the left side of the resulting image is visibly darker than it should be - it should be a copy of the left image pixels, because the right image is not supposed to contribute there at all. Images a.tif and b.tif will be attached. Both v3.2 and v4.0 have this problem. If I change images size, or take slightly (few pixels) bigger images and crop them to the same size (i.e. change content a bit) OR *switch the order of the 2 input images on the command line* the problem goes away. I examine the effect by looking at a difference image between the output and the left input image and look at pixel on the left side. The expected values are exact 0s, as enblend is not supposed to touch those pixels. However, I see up to 10 intensity steps differences. Here is gets interesting. When there is a problem, both v3.2 and v4.0 show about 10 steps differences. However, when there is no problem v3.2 always has 0 difference and v4 always has up to 1 step difference in different rgb channels which is a bug of its own, as it touches the pixels in an unpredictable manner. 
This was observed on both Mac and PC ( under VMWare Fusion). Binaries were downloaded from sourceforge, standard versions. In the attached zip, a.tiff and b.tiff are input files, c.tiff is the difference between a.tiff and the blended output with gain applied for visibility. I expected the left side of the image to be 100% black, but it not. c.tiff did not fit in the attachment limit.