You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bilinear filter shader code in compat: true mode is based on the avs BLEND4 code. This calculation produces inaccurate but more avs like results. Now the bug is this: In AVS if you use DM (with bFilter) on a white screen, the final filtered pixels will all be rgb(253,253,253). This works for the Webvs shader too, except that for some pixels the value comes to exactly rgb(255,255,255). This is not noticeable for most cases, but if you apply a colormap or a clip etc. these odd pixels start to show up as weird artifacts.
I've also figured out that this occurs when product of cornoff.x and cornoff.y is divisible by 255, which causes the sum of a1 to a4 to become exactly 255 without any flooring errors (unlike the remaining pixels) causing the output pixel to be exact white. Suprisingly though, the same problem should in principle happen in avs BLEND4 code as well (https://github.com/visbot/vis_avs/blob/master/avs/vis_avs/r_defs.h#L328), but it doesnt.
Will have to step through the AVS code to figure out why this happens. Any one with AVS build setup, please help!.
The text was updated successfully, but these errors were encountered:
Bilinear filter shader code in compat: true mode is based on the avs BLEND4 code. This calculation produces inaccurate but more avs like results. Now the bug is this: In AVS if you use DM (with bFilter) on a white screen, the final filtered pixels will all be rgb(253,253,253). This works for the Webvs shader too, except that for some pixels the value comes to exactly rgb(255,255,255). This is not noticeable for most cases, but if you apply a colormap or a clip etc. these odd pixels start to show up as weird artifacts.
I have written a test case to bring this out https://github.com/azeem/webvs/blob/master/test/DynamicMovement.test.js#L104
Basically, this test clips off values above rgb(253, 253, 253) to show the artifacts. The result looks like this:
I've also figured out that this occurs when product of
cornoff.x
andcornoff.y
is divisible by 255, which causes the sum ofa1
toa4
to become exactly 255 without any flooring errors (unlike the remaining pixels) causing the output pixel to be exact white. Suprisingly though, the same problem should in principle happen in avs BLEND4 code as well (https://github.com/visbot/vis_avs/blob/master/avs/vis_avs/r_defs.h#L328), but it doesnt.Will have to step through the AVS code to figure out why this happens. Any one with AVS build setup, please help!.
The text was updated successfully, but these errors were encountered: