All image-editing software gets scaling wrong

It's not that being gamma-aware is "right" and most software does it "wrong" for speed. In many contexts, RGB values don't have gamma associated with them, just as they don't have ColorSync profiles or whatnot, or if they have one, it was just invented at some stage of processing. (Using the current screen gamma would be pretty arbitrary for an image editor.) Trying to "convert" between different gamma values during processing likely will do more harm than good if your…

I wrote the Lanczos3 scaler that Picasa uses (about 14 years ago!), and it doesn't (by default) correct for gamma. For most images & kernels, you can get by with doing math in about 31 bits total precision (a bit for underflow clamping), so that's the magic speed improvement from ignoring gamma on old 32-bit architectures. If you gamma-correct, your sources will need to be 10-12 bpc after transformation, and you'll need >32 bits of integer precision for large kernels…

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). This completely…