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 Bug
Hunters, 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.
_______________________________________________
Mailing list: https://launchpad.net/~hugin-bug-hunters
Post to : [email protected]
Unsubscribe : https://launchpad.net/~hugin-bug-hunters
More help : https://help.launchpad.net/ListHelp
