r1029: Fix threshold rendering for non-OpenGL rendering by using alpha
commit0d916ff191c2f5b00a0577c5182bccdbfab283fb
authorJohannes Sixt <johannes.sixt@telecom.at>
Mon, 24 Sep 2007 18:54:24 +0000 (24 18:54 +0000)
committerJohannes Sixt <johannes.sixt@telecom.at>
Mon, 24 Sep 2007 18:54:24 +0000 (24 18:54 +0000)
treebf0b7a703407bbb1905b1e972dfc8ab704ac6696
parentfb5a29bfcc2fc9a8b8c3fe30f5395b5219bc00ba
r1029: Fix threshold rendering for non-OpenGL rendering by using alpha

Standard rendering was out of sync with OpenGL rendering, resulting in
unexpected output when switching from standard to OpenGL rendering in
compositor, or when rendered to file.

The problem did not manifest when working with a single track, only when
overlaying. The problem was when the video source supports transparency, the
white pixels are drawn opaque and black pixels are transparent. These are
not useful choices as they make the Multiply overlay operation
ineffective.

Specific example:
1. Import a video clip and duplicate the video to two tracks.
2. In the top track, apply Threshold. Choose overlay mode "Multiply".

Expected result in compositor: Pixels brighter than the threshold display
normally, and pixels darker than the threshold are black.

Actual result: Output is original video clip, unchanged.

Problem: Pixels brighter than the threshold multiply the original image by
1, and pixels darker than the threshold multiply the original image by 0.
But the dark pixels also have alpha = 0, so no multiplication actually
occurs for dark pixels. The entire image is effectively multiplied by 1.

Solution: Draw both white and black pixels with alpha = 1.

Patch by Craig Lawson.
plugins/threshold/threshold.C