Talk:Lanczos resampling

Serious errors in the 1-D presentation of the filter and displayed algorithm

If you look at the 1-D image of the filter results, with filter width 1, it becomes evident that the filter has not been normalized against the sums of the kernel weights (see the sum, which only multiplies, but does not normalize), as the interpolated signal dips between the values, generating a clearly higher-frequency signal than is actually present in the original. This is blatantly incorrect. If there are no objections, I will fix this page shortly.Warma (talk) 14:39, 18 April 2017 (UTC)

Why sinc filter is optimal for resampling

The data we are dealing with here is sampled data, and as such can be assumed to be bandlimited to the Nyquist frequency of the sampling process. According to Nyquist theorem, the original signal (i.e. continous time signal) can be reproduced without any loss by lowpass filtering a series of delta impulses defined by the sample values using a ideal lowpass filter. A ideal lowpass filter's impulse responce is defined by the sinc function. —Preceding unsigned comment added by Abjo (talk • contribs) 15:59, 13 January 2009 (UTC)

Why is it better than bicubic?

Dumb leading question, why is it better than bicubic?

• Results are realy similar to bicubic, but a little bit sharper. --ManiacK 17:10, 12 May 2006 (UTC)
• Without multiple lobes, it is no better than bicubic. With multiple lobs, it is mathematically better, but visually worse because of ringing artifacts. Yet another case where theory does not match reality. --anon user
• The report of a "blind user test" (! 8-) proves nothing by itself. Was the test properly done? (Did the experimenter worry about gamma, dark/light clipping, etc.?) What were the images? (fuzzy, sharp, contrast-stretched, ...?) What were the evaluation criteria? ("looks nicer", "looks sharper", "looks more natural", "looks more like the original", or something else?) --User:Jorge Stolfi 143.106.23.149 18:27, 17 April 2007 (UTC)
• In any case, a reconstruction filter R (used when enlarging an image I) should be matched to the sampling filter S (used when capturing the image I from the real world, or when producing it by reducing a larger image Q) and to the amount of quantization noise N. There is no "absolute best" filter R; the best R depends on S and N. Unfortunately, the S of scanners and cameras is usually unknown (although it can be measured with proper test targets and some image analysis). --User:Jorge Stolfi 143.106.23.149 18:27, 17 April 2007 (UTC)
• In any case, JPEG-coded images are unsuitable for any serious image processing, unless they are captured at the highest possible quality setting and/or are substantially reduced in size AFTER conversion to some lossless format. Note that JPEG uses a non-linear non-uniform encoding which creates artifacts at the boundaries of its 8x8 processing blocks --User:Jorge Stolfi 143.106.23.149 18:27, 17 April 2007 (UTC)

Good only in theory?

I find the claims of lanczos resampling being only theoretically good but bad in practice, very dubious. I have done tests with both video and audio and in both cases lanczos seems to have superior after-resampling quality to any other method I've tried, except for hq2x and other methods specifically finetuned for pixel content at certain ratio. --Bisqwit 08:25, 29 April 2007 (UTC)

• The {{fact}} template remained for two months, I removed the unsourced claim now. --Bisqwit 15:20, 8 June 2007 (UTC)

• Some interesting tests there. Too bad they were done with a black background. Had you use a grey background, you would've noticed dark rings appearing around the bright areas using the Lanczos filter and possibly several others. These do not appear with a black background because, obviously, it doesn't get much darker than zero. 130.89.228.82 (talk) 01:35, 19 February 2008 (UTC)

• Hmm, you're right. Therefore, I created a new test. It does show the "rings" you mention, appearing in such a stark upscaling as this. However, in the same breath, I'd say that it does the best job in preserving the contrast of the white cross, and keeping the aliasing off the yellow line. Catrom comes quite close, though. I also added downscaling tests. In that test, such "rings" are not observed, and it does among the best job in preserving the detail in the pillars and avoiding moire effects in the platform. However, mind you that for the purposes of Wikipedia, this is all original research, so it cannot be used for the article. --Bisqwit (talk) 07:22, 19 February 2008 (UTC)

• Of course original research can't be used, but it might point out an article is incomplete. I doubt nobody ever noticed something this obvious in a peer reviewed article. 130.89.228.82 (talk) 14:49, 19 February 2008 (UTC)

• It's been pointed out in the literature that Lanczos gives ringing artifacts. "Truncating the sinc filter is commonly known to cause unwanted artifacts, for example ringing." [1] Unwindowed Lanczos is theoretically ideal simply because its frequency response is the rectangle function, so it's optimal in the sense of Fourier (frequency) analysis, but not necessarily in terms of subjective human assessment. - Connelly (talk) 20:58, 28 October 2008 (UTC)

Are there any decent interpolating functions that don't give ringing artifacts? I don't think so. Certainly the "ideal" infinite sinc has more ringing artifact than any decent windowed sinc, including the Lanczos. Dicklyon (talk) 23:03, 28 October 2008 (UTC)

I don't know. People may have developed filters that specifically suppress ringing, but I'm not familiar with that area. - Connelly (talk) 00:15, 30 October 2008 (UTC)

Things like Photoshop's "softer bicubic" have less ringing, but consequently more blurring. There is no single criterion for these things, so no real ideal or optimum. Just use what you like for your application. Dicklyon (talk) 03:32, 30 October 2008 (UTC)

Here are some comparative tests: http://www.dylanbeattie.net/magick/filters/result.html. –jacobolus (t) 19:49, 10 June 2010 (UTC)

Also, a lot of helpful information here: http://www.imagemagick.org/Usage/resize/. –jacobolus (t) 19:52, 10 June 2010 (UTC)

Size of the contribution[] array in the example code

The original example code had the contribution array length specified as dest_len. A number of readers pointed out that the array maximum length should be src_len.

Here is the verification. The maximum dimension accessed contribution[] is nmax, due to the loop bounds.

• where nmax = min(src_len, support * 2)
• where support = 3 / min(factor, 1)
• where factor = dest_len / src_len
• i.e. nmax = min(src_len, 6 * max(src_len / dest_len, 1) )

if dest_len = 1, then nmax indeed equals src_len. So the correction is just. Imagemagick actually initializes the array size as 2*max(support,0.5)+3. But I guess, src_len is just as good. --Bisqwit (talk) 15:58, 6 December 2007 (UTC)

2D?

What is the kernel in 2D? is it just the tensor product of the kernel in 1D? 155.212.242.34 (talk) 21:31, 21 December 2007 (UTC)

For "2D" you just apply the filter in one direction, then in the other direction. The filter is "separable" so it's the same whether you do it horizontally first then vertically or vice-versa, thus reducing the problem to one of applying two separate "1D" operations. 136.186.72.46 (talk) 05:45, 14 November 2012 (UTC)

If you apply first in one dimension and then in the other, you by definition are making a separable 2D filter. Unfortunately, a filter made this way from a Lanczos filter has a sort of waffle-pattern impulse response, and quite non-isotropic transfer function. With a=2 it's not too bad, since the negative lobes are small. Dicklyon (talk) 05:56, 14 November 2012 (UTC)

Hey I'm no expert, but the 2-D kernel is definitely not separable into two one dimensional operations. Lanczos takes nearby points into account to create the interpolated value- Consider a point that is to the "northeast" of the interpolation location. By applying the operation in two 1-D passes, only the points to the "north", "south", "east", and "west" will be taken into account, at any value of a. The operation should take diagonal points to the "northeast", "northwest", "southeast", and "southwest" into account as well.

This is wrong. The comment suggests taking the output of the first 1-D pass and feeding it into the second 1-D pass. This process will allow information to propagate from the diagonal points. To be concrete, imagine the vertical pass is done first. Then information from the "northeast" will propagate into the "east" point after this pass. After the horizontal point, the new "east" - which already included an update from the "northeast" - will be used to update the central point. — Preceding unsigned comment added by 18.82.2.102 (talk) 23:51, 15 November 2018 (UTC)

Window function

Why is the window function based on sinc rather than something simple like a polynomial? Is there a good reason to use this particular window function? 155.212.242.34 (talk) 22:21, 21 December 2007 (UTC)

Since a sinc function is an ideal lowpass filter, a windowed sinc function is usually a pretty good lowpass filter. Lanczos chose to use the central positive lobe of a wider sinc as the window. I don't know why, but it seems to work well. Dicklyon (talk) 08:14, 22 December 2007 (UTC)

The ideal filter is the sinc-Funktion and in the frequency domain its a box. If you are convolut these box with another box to limit it to your windowsize it means in the spatial domain a multiplication of the sinc-window with a streched sinc-function. 130.149.241.174 (talk) 08:50, 15 April 2009 (UTC)

That's not quite true, since the functions being multiplied in the time domain are not sinc functions, but truncated sinc functions. Therefore the frequency domain effect is not at all close to a convolution of two boxes. Dicklyon (talk) 18:46, 15 April 2009 (UTC)

Why not? - its the other way round. Convolution in frequenzy domain means multiplikation in spatial domain. The representation of convolution of 2 boxes in the spatial domain is a multiplication of 2 sinc-functions. Shure if you're applying a fft its truncated, but mathematically its the same.130.149.246.14 (talk) 08:43, 22 April 2009 (UTC)

If you multiplied two sincs in the time domain, then that convolution of boxes in the frequency domain would be a transfeer function with flat passband and stopband segments at gains of 1 and 0, respectively, and a linear transition segment between them; this is not what the Lanczos filter looks like, though. If you then account for the truncation window you can get to the correct answer. That's all I'm saying. Dicklyon (talk) 17:28, 22 April 2009 (UTC)

Why the sinc function?

"it more closely approximates the optimal resampling filter, the sinc function": It is not obvious to our average reader why the sinc function would be the optimal resampling filter, in general, or more specifically, for image data. Closely related to this is also the question as to in what sense the sinc function is optimal, in other words, what is the performance function that the sinc function maximizes? Shinobu (talk) 22:11, 11 January 2008 (UTC)

I linked "optimal resampling filter" to the sinc filter article to help explain this. What's being optimized is aliasing, under the assumption of a band-limited underlying original that you have samples of, and handlimited reconstruction. It's not necessarily an accurate characterization of the image resampling problem in general, but it's the one that's mathematically tractable. The bigger question is in what sense is it true that "it more closely approximates" this. Relevant considerations are discussed and anayzed in the window function article, where the sinc window is categorized as a "high-resolution" window, as opposed to a high-dynamic-range window; for images, this is a good choice, but other windows in that class are equally good. Dicklyon (talk) 22:54, 11 January 2008 (UTC)

Is this really optimal for images? Sinc function is optimal when the signal is bandpassed before conversion to prevent aliasing, like audio, but images are not bandpassed before conversion, which is why they alias. 71.167.67.250 (talk) 23:34, 29 June 2008 (UTC)

Selected radius

The article does not mention explain why one should choose a particular value for $a$, the radius in the Lanczos formula. Imagemagick uses the value of 3, so I have always used it in my own code, but I don't really know why one value would be better than some other. Is there an explanation somewhere? Could the article be improved by adding such explanation? --Bisqwit (talk) 09:10, 6 February 2008 (UTC)

It's a tradeoff between computational cost and accuracy (filter cutoff sharpness at Nyquist); 2 and 3 are reasonable values, depending on how accurate you're trying to be. For something like audio instead of images, larger n might make sense. Dicklyon (talk) 15:52, 6 February 2008 (UTC)

When applied to image resampling, it's a tradeoff between sharpness and ringing artefact. 3 is a common compromise in image resampling. 2 is softer and not really worth it, 4 is much sharper but results in greater ringing artefacts. If you're *downsampling*, you could get away with 4 and get great sharpness. 136.186.72.46 (talk) 05:51, 14 November 2012 (UTC)

Negative values

The article points out the window function reaches negative values but doesn't point out the significance; negative values in the window function can cause values in the resulting signal that are outside of the bounds of the original signal; for example if you use the Lanczos filter on a rect function, the result will drop below 0 outside of the edges of the rectangle and can pop over 1 inside the edges. Put differently, when using a filter on a dirac delta function the filter's window will re-appear, complete with negative values. Bicubic interpolation has a similar problem. In terms of image processing, this may in some cases make the filter less suitable for images with sharp corners. 130.89.228.82 (talk) 01:35, 19 February 2008 (UTC)

Less suitable than what? All good interpolation filters have this property, because otherwise they're too soft. Dicklyon (talk) 01:49, 19 February 2008 (UTC)

Less suitable than a softer filter, perhaps. 130.89.228.82 (talk) 14:49, 19 February 2008 (UTC)

Perhaps, though at n=2 it's about like a soft cubic spline. For n=3 it's a bit sharper, which is usually judged to make it look better, not worse. Dicklyon (talk) 16:31, 19 February 2008 (UTC)

It's a tradeoff between computational cost and accuracy (filter cutoff sharpness at Nyquist); 2 and 3 are reasonable values, depending on how accurate you're trying to be. For something like audio instead of images, larger n might make sense. Dicklyon (talk) 15:52, 6 February 2008 (UTC)

Amount of overshoot

For practical use, it would be important to know the maximum amount of over/undershoot (as a fraction of the input sample range). Thus one could avoid clipping by pre-scaling the samples to use less than the full quantization range. --Jorge Stolfi (talk) 00:57, 8 January 2013 (UTC)

Alternatively, over/undershoot only happen if the input signal has abrupt transitions, e.g. from 0 to 1 in a black-and-white image. However, they should not occur if the input signal has been properly sampled (with a sampling kernel whose spectrum falls off smoothly before the Nyquist limit). This should be the case for photographs and scanned images, whose pixels are intentionally fuzzy so as to avoid Moire effects and jaggies. This "well-filtered" property should be preserved when a signal is upsampled with Lanczos filtering. Could anyone provide precise statements in this regard? --Jorge Stolfi (talk) 00:57, 8 January 2013 (UTC)

Indeed, there must be a linear formula involving 2a consecutive samples that bounds the interpolated signal in the interval between the two central samples. This formula would provide a test for "properly filtered" input signal. Is this available somewhere? --Jorge Stolfi (talk) 00:57, 8 January 2013 (UTC)

Code quality

The C++ example is of certainly poor quality as it uses some very C style code structure along with precise-imperfect data types with others which are in the mismatching domains. For example, there's an int compared to a double, another short-coming in the code is that it expects the Radius value as a template-parameter, which will cause the compiled binary to have a different code generated for each Radius value used. Thus it will certainly cause excessive amounts of code-bloat. Radius can perfectly be a function parameter. Also someone has to get rid of all those statics... Come on, this is a single file example not a commercial product which needs to block access to non-interfaced functions within certain files. —Preceding unsigned comment added by 91.155.47.44 (talk) 15:33, 29 June 2008 (UTC)

• Thank you for your questions. I will try to answer your concerns.
  ① "int compared to double": There is one in "if(x <= -Radius || x > Radius)". However, the code would not change meaning even if Radius were a double. The cutoff is supposed to be sharp, from a value 3.00000000000000 or whatever the Radius is selected to be ― generally an integer. So it makes sense to use an integer there. Since the Radius is a template parameter, it is a constant, and the compiler can emit a floating point comparison there instead of an integer comparison, if it is faster on the platform. Not so if it were a regular parameter.
  ② As for code bloat caused by template expansion, I selected to make a Radius as a template setting instead of a parameter in order to utilize the constantness optimizability as exampled above, and because, for fact, the Radius is indeed supposed to be constant for the whole duration of the Resample function, so it doesn't make sense (from a performance viewpoint) to make the compiler wonder whether it may change, and thus consequently it having to factor the integer variable to the equation every time, instead of optimizing it. It also gives better inlining opportunities. Also, from my viewpoint, each lanczos function for a different radius is indeed a different lanczos function.
  ③ Regarding the static settings: Because this example code was clearly written as a self-standing program with no API exported outside, it makes sense to document that aspect of the program. Without static, it would appear that the function is supposed to be used from somewhere outside the shown code. Also, it produces more optimal resulting executable, because the compiler can find all the locations where the function is invoked, and if it chooses to inline all of them, it knows that the function is not called from anywhere else, and thus, it does not need to assemble a separate copy of the function. ―-Bisqwit (talk) 07:19, 1 July 2008 (UTC)
  • I think you may be mistaken about the ability of C++ compilers to optimize const function arguments. You may want to try it as an argument and check the disassembly.
  • Similarly with the static - modern compilers will create a duplicate of the function for inlining, then the linker will strip the unused version. The only reason to add 'static' might be to reduce compile times.
  • 68.148.21.103 (talk) 21:33, 6 July 2008 (UTC)

The article says that the code is hard-coded for a radius of 3. Is this only because FilterRadius is set to 3, or will there be more work required to make the algorithm use a higher radius value? /85.228.39.162 (talk) 06:46, 14 August 2008 (UTC)

• Only FilterRadius needs to be changed. --Bisqwit (talk) 13:23, 15 August 2008 (UTC)

Great, thanks. I've got another question though, about the example pictures at the top. How come the jpeg artifacts are removed only for the resampled image? It doesn't seem like a fair comparison if other improvements have been made. Also, how were the artifacts removed? /85.228.39.162 (talk) 22:12, 22 August 2008 (UTC)

My guess is that the implication is that the JPEG artifacts of the original image are also removed in the lanczos scaling. Note that the JPEG artifacts being talked about are not those that are present in the pixel-to-rectangles-scaled version of the original picture. As for why would lanczos scaling remove those artifacts, my guess is it has something to do with mathematical averages and frequencies, but this is merely some of the wikipedia-hated original research, so feel free to ignore me. --Bisqwit (talk) 07:56, 23 August 2008 (UTC)

I am the original uploader of the two images. As clearly stated in their description, the modified image has undergone a two-way process: a Lanczos rescaling followed by a trimming of lighter sections of image's gray levels. I thought the description was clear. Obiouvsly, one could choose a better sample image, but this was the one I had ready when I contributed to the article. Feel free to improve it. Amux (talk) 00:50, 29 October 2008 (UTC)

I have no idea what "clearly stated" may mean in your reply. The caption does not parse. Your reply parses, but is too vague. Could you explain exactly which steps one should do (in some image processing program) to get from the source to the destination? (iz) --71.132.202.174 (talk) 01:04, 1 November 2008 (UTC)

I think I finally see what "JPEG artifacts were removed changing image's transfer function" was meant to indicate, and I agree it's not clear. The other image says "with JPEG artifacts". It's really not at all clear how JPEG is involved at all in an image resizing comparison. Maybe we need to reset, start over, and make an image comparison that we can understand. Dicklyon (talk) 03:24, 1 November 2008 (UTC)

Why must be this code so obtuse? Witness the fact that nobody (?) noticed that

• `contribution' array is not used, and
• the result array is shifted 1 pixel to the left (due to adding 0.5 twice, instead of adding and subtracting; check with magnification=1).

It does not help that 1 is denoted as `blur', and an extra parameter `scale' with unexplained semantic introduced...
I think that for best results, the `scale' part should be delegated to the caller. So the example script should have an extra parameter to force the "radius" of the filter to be 1 when it is used for upscaling. (iz)

Source code removed

Seeing that the example C++ code has its comments, I found it natural to leave that discussion behind and remove it from the article. Source code is not encyclopedic and is discouraged by WP:NOT. --Berland (talk) 18:48, 8 November 2008 (UTC)

Some Points

It's important that filters be applied to gamma-corrected images. The filtering operation should be performed on linear luminance, or essentially you are applying a kernel with a distorted shape that is not turly the lanczos-sinc function.

Another point is that narrowing the window too much will drastically distort the behavior of the sinc function and nullify the theoretical advantages of approximating the idea low-pass filter. I would recommend alpha=4. I'm skeptical that alpha=2 ("Lanczos2") would be as good as catmull-rom cubic filter, but I'm not aware of a good scientific study of very small filter kernels. At Bell Labs, I did a study of cubic functions that appeared in SIGGRAPH 88, which folks can look at. There are quite a few issues - high frequency leakage, ringing, blurring (subband attentuation), imaging or post-aliasing, etc. DonPMitchell (talk) 21:05, 29 December 2008 (UTC)

Thanks for the pointers Don, and thanks especially for your paper, which very clearly explains a number of issues which are often conflated or ignored. The prealiasing/postaliasing distinction is particularly useful – I’d just been making this distinction at aliasing, but these are both referred to as “aliasing” so the language was awkward; I’ve been referring to them as “sampling aliasing” and “reconstruction aliasing”.

Thanks again – I’ll link to your paper where useful, as it clarifies many points.

—Nils von Barth (nbarth) (talk) 03:15, 16 April 2009 (UTC)

Actually, by gamma corrected, I think Don means linearized. But, while his point has some theoretical justification, in practice it is sometimes the opposite. That is, it may work better to apply filters to nonlinearly gamma-compressed images. The reason is that undershoots in the gamma-compressed domain are less objectionable. This is especially true for sharpening filters, but also for any filter that rings. There's no really good theory to invoke here, since there's no such thing as a bandwidth-limited real intensity image. Some advocate filtering on log-compressed images (as in Oppenheim and Stockham's "Image Processing the Context of a Visual Model" or something like that), due to some theory about homomorphisms that can separate multiplicative lighting and reflectance effects. But usually a power-law nonlinearity like a gamma compression is a happy medium. Dicklyon (talk) 03:33, 16 April 2009 (UTC)

I recall some folks at Adobe also making the claim that filtering un-gamma-corrected images was OK. I'm very skeptical about that, it doesn't jive with the results I've seen in my research. At Bell Labs, we prepared both video (720p) and still images with careful application of gamma correction and filtering, and the results were stunningly sharp and free from visual defects. Some of this was to generate artificial test images for HDTV testing that had high contrast and sharp edges. We saw aliasing artifacts when we failed to perform the correct gamma transformations before and after filtering. DonPMitchell (talk) 22:49, 27 May 2009 (UTC)

The “folks at Adobe”, at least for Photoshop, do everything to gamma-compressed images (e.g. computing “luminosity” as a weighted sum of gamma-compressed components, and compositing partially transparent images in gamma-compressed space). It’s not clear to me that there’s much theoretical basis for any of it, and the speed penalty is pretty irrelevant these days. As far as I can tell the only argument for not changing it in newer versions is making sure that they work identically to previous versions. What I really don’t understand is why they added “bicubic sharper” and “bicubic smoother” interpolation in one of the recent versions, without adding a “lanczos in linear space” option (or something) too/instead. Oh well. –jacobolus (t) 22:37, 10 June 2010 (UTC)

Dick: I imagine possible improvement in sharpening just of grayscale images in gamma-compressed instead of linear space, or perhaps of images transformed to some approximation to LMS cone coordinates and then gamma-compressed... but doing sharpening in a gamma-compressed RGB (e.g. in Photoshop) in my experience introduces obvious color artifacts (which is to say, lightness artifacts, because two different saturated colors next to each-other are at different points along the gamma curve in each component). When you say “in practice”, are there any links to more systematic investigations that show improvement using gamma-compressed images instead of linear ones? –jacobolus (t) 16:25, 11 June 2010 (UTC)

In visual processing

"The human eye does not detect frequency directly (unlike the ear)" - clarification - the ear receptors are directly connected to resonators at specific frequencies, whereas the eye detects amplitude in three overlapping colour/frequency bands. Hence one can say that the ear does detect frequency directly and the eye does not. 81.187.100.246 (talk) 13:45, 28 March 2012 (UTC)

• These comments were pruned since they seemeded to stray off the topic of the article:

A common misconception is that the sinc filter should be the best possible image filter, because of its ideal frequency response. This is only true for bandlimited signals which were sampled after an antialiasing filter, which is not typically the case for images. The human eye does not detect frequency directly (unlike the ear). However, vision utilizes specialized receptor patterns that detect things like localization, edge contrast and contour. The special role of edge contrast in vision is why the negative lobe of the Lanczos filter.

--Jorge Stolfi (talk) 00:30, 8 January 2013 (UTC)

x=0

sinc fn is already zero at x=0 , so is sinc * sinc.

The special case for x=0 is trivial and unnecessary. —Preceding unsigned comment added by 95.176.113.11 (talk) 23:31, 27 April 2011 (UTC)

You seem to be confusing the problem of calculating the sinc on a computer, as it tends to zero, with maths theory.

sinc(0)=1 but if you try sin(0)/0 on a calculator you'll have problems. That is a problem of your method, it does not change the theory or require a piecewise definition.

About neutrality of images

The caption of the second image suggest that it has not *just* been Lanczos resampled. Either the caption is wrong, or the images should be changed/removed since if the caption is right it gives too favourable an impression. — Preceding unsigned comment added by 82.139.81.0 (talk) 02:25, 13 November 2012 (UTC)

Yes, as examples go, that one sucks. Dicklyon (talk) 03:15, 13 November 2012 (UTC)

What about discrete values of X?

All the graphs of the sinc and lanczos functions on this article show X being continuous from -A to A (including values like 2.3). However, in data processing (such as image resizing interpolation) the positions of the pixels (the values of X) are going to be discrete. How is a discrete-position signal (such as an image, where values of X will only be integers) processed using the lanczos kernel? Can someone post an example of that here, including a diagram of how the algorithm works in such processing? Benhut1 (talk) 10:04, 22 August 2014 (UTC)

Typically one samples it at the discrete locations of interest, and then renormalizes the sum to 1. Dicklyon (talk) 02:37, 23 August 2014 (UTC)

Logarithmic Domain Does Not Help

The article states "In some applications, the low-end clipping artifacts can be ameliorated by transforming the data to a logarithmic domain prior to filtering. In this case the interpolated values will be a weighted geometric mean, rather than an arithmetic mean, of the input samples."

In testing, this was not only false, I found artifacts significantly *increased*.

I would suggest removing this or citing evidence to support this claim. (I've heard of original research. Making this... original hypothesis?)

Methodology: 1. RGBA8888 source image was split into individual 8-bit planar channels 2. Each channel was converted to 32-bit floating point 3. A variety of logarithmic transforms were performed (log (aka ln), log2, log10), with and without x+1. 4. Each channel was rescaled via a floating point Lanczos implementation (Apple's Accelerate framework, vImageScale_PlanarF) 5. Each channel was transformed back to the linear domain (powf(base, x) - const). 6. Each channel was converted to 8-bit (saturating), then re-interleaved to an RGBA8888 dest image.

Artifacts: 1. Clipping: did not appear to significantly differ. 2. Ringing: significant increase 3. Chromatic aberrations: random color noise was present in low-mid intensity pixels. Not seen without logarithmic scaling applied.

Summary: A significant increase in artifacts at considerable computational expense. — Preceding unsigned comment added by 184.166.80.233 (talk) 21:28, 20 September 2014 (UTC)

• Response to Objection: The theory was that a gamma ramp acts as a pseudo-logarithmic encoding, and a generalized logarithmic encoding might be more appropriate. When you converted from 8-bit to float, you did not indicate that you removed the gamma ramp before applying a logarithmic conversion. If you did not, then you were essentially applying a logarithmic operation twice. — Preceding unsigned comment added by 2001:4898:80e8:3:7031:3199:a042:4f1b (talk) 21:24, 12 October 2018 (UTC)

Better images needed

The black and white images of sheet music (File:Lanczos interpolation - Sheet music, original.jpg and File:Lanczos interpolation - Sheet_music, interpolated.jpg) used in the Multidimensional interpolation section don't seem to show much before and after difference. In fact, in my browser they both look blurry and pretty awful! Perhaps this is due to the thumbnail size? But the reader should not be forced to go offsite to Wikimedia Commons. Larger images aligned horizontally instead of vertically may be better. Senator2029 “Talk” 02:46, 15 October 2014 (UTC)

Two-dimensional transform incomplete

A jan. 19 edit has stated that that the Lanczos kernel is not separable and implementations use $L(x,y)=L(r)$ contrary to what Burger says. Is this true? At least GraphicsMagick seems to use $L(x,y)=L(x)\dot L(y)$ as the article used to.

If both forms are in common use, should not both be explained here? — Preceding unsigned comment added by 201.27.75.229 (talk) 23:19, 24 February 2017 (UTC)