The primary reason for this problem is twofold: 1. People writing image scaling libraries are big on speed. Many, like libswscale, are intended for realtime

The primary reason for this problem is twofold: 1. People writing image scaling libraries are big on speed. Many, like libswscale, are intended for realtime video playback on systems without graphics overlay acceleration. They contain truckloads of shortcuts to cheat wherever possible in the name of performance. 2. A "correct" method requires one of two things: A. Performing one LUT per input pixel to the tapfilter, plus one LUT per output pixel (see http://news.ycombinator.com/item?id=1142084 http://news.ycombinator.com/item?id=1142084). This completely eliminates any possibility of SIMD. Other LUT schemes are also possible, like LUT[pixelX][pixelY]. B. Converting the entire image to linear 16-bit colorspace internally, then converting it back. This adds a slow preprocessing (and postprocessing) step and halves the speed of image processing. Since both have huge speed impacts, most people writing graphics libraries don't like to do them. Oh, and standard GPU-accelerated overlays can't really do either of these.