# How do you choose the optimal number of taps in a windowed image scaling filter?

I'm attempting to use a filter to scale an image and for the most part, I have something that appears to work. But now I want to be able to generate a filter with an optimal number of taps. I know in general that the more taps, the better. But there are diminishing returns in how much each additional tap will increase the quality of the image. So how would one go about picking a number of taps that makes a good tradeoff between implementation complexity and image quality? Are there standard measurements that would allow different filters to be evaluated to some "ideal" filter?

Thinking about this more, I think this is really two questions. One is a matter of deciding which windowed sinc to use (in this case, I've already settled on using lanczos2 or 3) -- that is a more general question that has various tradeoffs depending on the application. But once that decision is made, the number of taps is easily determined. For lanczos2, the ideal number of taps is 4 and for lanczos3, the ideal number of taps is 6. The reason it's not 5 or 7 is that one of those taps will always be zero due to the windowing.

In the more general case, I think the easy way to state how many taps to have for a given window is to simply say:

taps = max - min


In the case of lanczos2, the max is 2 and the min is -2. Therefore, taps = 4.

• This should also be marked as a community wiki post. I don't have the ability to do so here yet, so I would appreciate it if someone else can mark it that way for me. Feb 7 '12 at 16:27
• Why would you like to make this a community wiki? Feb 7 '12 at 16:48
• What do you mean when you say diminishing returns? Feb 7 '12 at 16:55
• @Phonon I assume there is no one right way to choose the number of taps, so therefore it should be a community wiki since there will be more than one answer. Feb 7 '12 at 17:40
• If you're looking for an "optimal" solution, then you need to provide some optimality criterion. What application are you planning to use it for? What are your platform's primary constraints? Feb 15 '12 at 14:20

Images quantized to some bit depth have error due to the quantization. Your filter also introduces error, compared to using an infinitely large ideal filter. Using larger and larger filters, eventually you will arrive at a knee in the total error vs filter size diagram where those two errors are equal. After that the quantization error dominates so it doesn't pay off much to improve the filter further.

A commonly used error metric is peak signal-to-noise ratio.

• Good answer @Olli, but isn't that addressed with extended precision accumulators? (Of course we cannot extend indefinitely so perhaps that is the constraint, but we can scale interstage and still keep the accumulated error terms sufficiently below our datapath quantization noise floor) Apr 3 '17 at 13:10
• So no dispute to what you said but more of a question to confirm my own understanding: if you allow for extended precision accumulators, do you still see a knee as your filter size increases (assume we can extend indefinitely at log2(N).) Apr 3 '17 at 13:12
• @DanBoschen I mean the quantization error that someone else baked into the original image. Apr 3 '17 at 14:46