Talk:Lanczos resampling

message: 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)
thread_title:  Serious errors in the 1-D presentation of the filter and displayed algorithm 

message: 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)
thread_title:  Why sinc filter is optimal for resampling 

message: 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)
thread_title:  Why is it better than bicubic? 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

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

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

message: 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)
thread_title:  Size of the contribution[] array in the example code 

message: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  2D? 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Window function 

message: "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)
replies: text: 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)
thread_title:  Why the sinc function? 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Selected radius 

message: 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)
replies: text: 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)
replies: text: Less suitable than a softer filter, perhaps. 130.89.228.82 (talk) 14:49, 19 February 2008 (UTC)
replies: text: 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)

text: 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)
thread_title:  Negative values 

message: 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)
thread_title: Amount of overshoot

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Code quality 

message: 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)
thread_title:  Source code removed 

message: 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)
thread_title:  x=0 

message: 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)
replies: text: Yes, as examples go, that one sucks.  Dicklyon (talk) 03:15, 13 November 2012 (UTC)
thread_title:  About neutrality of images 

message: 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)
replies: text: 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)
thread_title:  What about discrete values of X? 

message: 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)
thread_title:  Logarithmic Domain Does Not Help 

message: 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)
thread_title:  Better images needed 

message: 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)
thread_title:  Two-dimensional transform incomplete