Item — HN Reader

The book "Digital Image Warping" by George Wolberg[0] goes into these tricks in great detail, as well as choices for the resampling filter.

The world is very different today, bilinear texture sampling is built into GPU hardware and is lightning fast. The idea that a sequence of skews might be more efficient is a curious relic of when CPU was considered a reasonable place to do image transformation.

[0]: https://www.amazon.com/Digital-Image-Warping-George-Wolberg/...

2 comments

I think that using a series of skew operations for rotation could still be useful. Bilinear/trilinear texture lookup will always look a bit blurry. Most graphics processing apps are still done using the CPU for most basic operations. And when the GPU is used, it's mostly compute shaders to get bit-accurate results (they could still be using the texture unit, though).

Real time graphics is of course a different matter.

That's interesting. The sheer operations still require interpolation (just that, you don't need to do 2D interpolation, 1D works out), so you still need to interpolate.

And the scaling also requires interpolation. So I'm not sure if it's better or worse in terms of bluriness.

> The sheer operations still require interpolation (just that, you don't need to do 2D interpolation, 1D works out),

Back in the day, the "rotozoom" coefficients were chosen at a nearest integer to avoid interpolation. This of course means that you can't continuously choose the value of the angle. Interpolation doesn't play nice with a palette-based image with a fixed number of colors anyway.

When palette and integers are not a restriction, higher quality interpolation (bicubic, etc) is also an option. Comes with tradeoffs, of course.

Using integer coefficients will also enable all kinds of opportunities for assembly-level optimization.

I see! But scaling surely requires 2D interpolation, then, right?

Scaling requires interpolation, but nearest neighbor sampling was good and fast enough for old school rotozoom effect.

Yeah. Ideally you'd use a mix of both: GPU texture lookup for live preview and slower, more accurate method for the final result.

There are still plenty of situations where low level software solutions are needed for graphics rendering on embedded hardware.