[HN Gopher] The magic (image resampling) kernel
       ___________________________________________________________________
        
       The magic (image resampling) kernel
        
       Author : BoingBoomTschak
       Score  : 70 points
       Date   : 2024-10-06 10:40 UTC (1 days ago)
        
 (HTM) web link (johncostella.com)
 (TXT) w3m dump (johncostella.com)
        
       | bhouston wrote:
       | Super cool. How did I not know about this before?
        
         | BoingBoomTschak wrote:
         | I was also pretty surprised, as I consider myself decently
         | knowledgeable in the field. Learned of it via
         | https://github.com/libvips/libvips/issues/4089.
        
       | BoingBoomTschak wrote:
       | These previous discussions (including the author in the second
       | one) were pretty fruitful:
       | 
       | https://news.ycombinator.com/item?id=10404517 (2015)
       | 
       | https://news.ycombinator.com/item?id=26513518 (2021)
        
       | pseudosavant wrote:
       | I was surprised I hadn't heard of this, or his related project
       | JPEG-Clear. I have thought for years that the JPEG-Clear method
       | is how responsive images should have been handled in a browser. A
       | single-file format that can be progressively downloaded only up
       | to the resolution it is being displayed at. If you zoom in, the
       | rest of the data can be downloaded for more detail. Doesn't
       | require complex multi-file image authoring steps, keeps simple
       | <img src> grammar, and is more efficient than downloading
       | multiple completely separate images.
        
         | meindnoch wrote:
         | JPEG-Clear? The guy "reinvented" progressive JPEGs?
        
       | svantana wrote:
       | I feel like this article is really overselling this filter. A
       | 4-point symmetric interpolation kernel can be parameterized as
       | [k, 1-k, 1-k, k]/2, i.e. it has a single degree of freedom.
       | k=-1/4 is bicubic, k=1/4 is this 'magic', and k=0 is bilinear.
       | Bicubic is sharper, and 'magic' has better alias rejection. Which
       | looks better depends on the image and the viewer's subjective
       | preference. For insta photos, it's probably better to go for
       | 'magic', while for text, one might prefer bicubic. Neither is
       | "simpler" as this article keeps suggesting, they just have
       | different filter coefficients, that's all. But any other value of
       | k is an equally valid choice.
        
         | BoingBoomTschak wrote:
         | It certainly is. Especially lacking in proper comparisons of
         | the final filter with the competition. I myself default to
         | RobidouxSharp for downscaling and something like
         | https://www.imagemagick.org/discourse-server/viewtopic.php?t...
         | for upscaling.
        
       | CyberDildonics wrote:
       | I guess anything is magic if you don't know how it works or if
       | you need some clicks to promote your personal site.
       | 
       | This is basically a slightly different gaussian kernel and the
       | "incredible results" of a small image becoming a larger
       | resolution blurry image is completely normal.
       | 
       | Also you don't want negative lobes in image kernels no matter how
       | theoretically ideal it is, because it will give you ringing
       | artifacts.
       | 
       | If you work with image kernels / reconstruction filters long
       | enough you will eventually learn that 90% of the time you want a
       | gauss kernel.
        
         | pixelpoet wrote:
         | > If you work with image kernels / reconstruction filters long
         | enough you will eventually learn that 90% of the time you want
         | a gauss kernel.
         | 
         | Strongly disagree, and my commercial software is known for its
         | high image quality and antialiasing. Gaussian is way too blurry
         | unless you're rendering for film.
        
       | DustinBrett wrote:
       | Would be cooler if images on FB didn't suck.
        
       | rnhmjoj wrote:
       | > Fourthly, and most importantly, as noted above: m(x) is a
       | partition of unity: it "fits into itself"; [...] if we place a
       | copy of m(x) at integral positions, and sum up the results, we
       | get a constant (unity) across all x. [...] This remarkable
       | property can help prevent "beat" artifacts across a resized
       | image.
       | 
       | So, basically the reason why this works better than other
       | visually similar filters is that it happens to satify the Nyquist
       | ISI criterion[1].
       | 
       | [1]: https://en.wikipedia.org/wiki/Nyquist_ISI_criterion
        
       | layer8 wrote:
       | In the "Bicubic: note the artifacts" comparison images, the
       | bicubic version, regardless of the aliasing, is less blurry and
       | has more detail than the "magic kernel" version. I therefore
       | don't agree that the latter is "visually, far superior". There is
       | at least some trade-off.
        
       | herf wrote:
       | This uniform b-spline is the same one used often as a "Gaussian"
       | approximation (three box filters) - see Paul Heckbert's 1986
       | paper here (apparently done at NYIT in the early 1980s with help
       | from Ken Perlin):
       | 
       | https://dl.acm.org/doi/pdf/10.1145/15886.15921
        
       | raphlinus wrote:
       | The page mostly talks about image resampling where the goal is
       | more or less preserving all frequencies, but it's also extremely
       | effective at implementing Gaussian blur. Basically, you do n
       | iterations of sampling by 1/2 using this kernel, followed by a
       | very small FIR filter, then n iterations of upsampling 2x using
       | the same kernel. Here, n is essentially log2 of the blur radius,
       | and the total amount of computation is essentially invariant to
       | that radius. All these computations are efficient on GPU - in
       | particular, the upsampling can be done using vanilla bilinear
       | texture sampling (which is very cheap), just being slightly
       | clever about the fractional coordinates.
       | 
       | It works well because, as stated, the kernel does a good job
       | rejecting frequencies prone to aliasing. So, in particular, you
       | don't get any real quality loss from doing 2x scale changes as
       | opposed to bigger steps (and thus considerably larger FIR
       | support).
       | 
       | I have some Python notebooks with some of these results, haven't
       | gotten around to publishing them yet.
        
       ___________________________________________________________________
       (page generated 2024-10-07 23:00 UTC)