Closed GoogleCodeExporter closed 9 years ago
doh! The *2 comparison is a little more efficient than /2, but is more
confusing to read, which lead to getting it backwards.
Good catch. Thanks for the patch!
Fixed in r562.
Original comment by fbarch...@chromium.org
on 6 Feb 2013 at 7:22
Re-opening, as one of the scaling tests crash. Seems unrelated
[ RUN ] libyuvTest.ScaleDownBy8_Box
unknown file: error: SEH exception with code 0xc0000005 thrown in the test body.
[ FAILED ] libyuvTest.ScaleDownBy8_Box (1 ms)
[ RUN ] libyuvTest.ScaleDownBy16_None
filter 0 - 5 us C - 4 us OPT
[ OK ] libyuvTest.ScaleDownBy16_None (1 ms)
[ RUN ] libyuvTest.ScaleDownBy16_Bilinear
filter 1 - 6 us C - 5 us OPT
[ OK ] libyuvTest.ScaleDownBy16_Bilinear (1 ms)
[ RUN ] libyuvTest.ScaleDownBy16_Box
unknown file: error: SEH exception with code 0xc0000005 thrown in the test body.
[ FAILED ] libyuvTest.ScaleDownBy16_Box (1 ms)
Its something to do with box filter scaling down with odd scale factors.
Original comment by fbarch...@chromium.org
on 6 Feb 2013 at 11:34
Yes, the box filter downscaling probably hasn't been tested much at all, since
the generic box filter downscaling function was impossible to invoke prior to
this patch.
Original comment by mar...@martin.st
on 7 Feb 2013 at 9:08
Yikes, I think you're right. We should reintroduce the bug you found :-)
r565 disables tests affected. Which allows other changes to be tested.
Seems to be the box filter horizontally reading too much.
If the sizes work out to integers, it should be okay. Or you can use
Filter_None.
Should have a fix shortly though.
Original comment by fbarch...@chromium.org
on 8 Feb 2013 at 2:33
Fixed in r571. Box down sampling was starting the initial sampling at middle
of box. This is correct for point or bilinear but not box filter.
Original comment by fbarch...@google.com
on 12 Feb 2013 at 7:07
Original issue reported on code.google.com by
mar...@martin.st
on 6 Feb 2013 at 6:08Attachments: