Talk:Image scaling

Overly casual language

This image shows the annoying effect that pixels of the original image are now squares

Not really very formal is it? 138.243.129.4 11:11, 30 December 2006 (UTC)

This is not currently an issue. yoyo (talk) 18:29, 5 April 2012 (UTC)

Image reduction

This article (and the linked articles) seem entirely focussed on Image enlargement. It would be good if reduction, and the effect of differing scaling routines on image quality were discussed. Particularly with regard to preservation of finer detail.

• With multi-megapixel cameras ubiquitous these days, I find I'm scaling images down for web publishing and emailing a lot. —Preceding unsigned comment added by EasyTarget (talk • contribs) 09:19, 11 June 2008 (UTC)
• Image reduction is important too! However, the old 'subsampling' page was hardly expansive. Unfortunately I'm searching for the knowledge, not myself an expert, and not myself therefore in a position to improve this content. Hopefully others will. —Preceding unsigned comment added by 62.109.53.3 (talk) 10:27, 29 October 2008 (UTC)
  • It is worth noting that the "downsampling" link in this article links to an article relating to signal processing, not image scaling. The downsampling article itself contains a disambiguation link to the article "subsampling", which in itself turns out to be a disambiguation page, which, on the topic of image subsampling, points back to this article. --Dolda2000 (talk) 23:37, 12 February 2010 (UTC)

Proposal: merge from Subsampling

This other article about image scaling should be merged here. Dicklyon (talk) 17:35, 9 August 2008 (UTC)

I concur. A general cleanup on image scaling articles is needed, so I added a few more merge proposals. --Berland (talk) 19:45, 9 August 2008 (UTC)

If Resampling is included in the merge, it should be the main article title, since it's more general than image scaling. It might be best to leave a separate article on image scaling, as there's a ton of specific techniques for images, and leave the more general resampling separate. Dicklyon (talk) 19:53, 9 August 2008 (UTC)

It is only the bitmap part of Resampling I possibly want merged. But this is not my main field, so if both Resampling (bitmap) and Image scaling are separate enough for their own articles, it is fine by me. --Berland (talk) 21:19, 9 August 2008 (UTC)

Yes, you are right; most of that article should be merged; what's left may need to merge somewhere else. Dicklyon (talk) 04:18, 10 August 2008 (UTC)

Agree wholeheartedly that the image scaling articles should be re-arranged.

An important distinction is between continuous tone images and pixel art, as the goals and techniques are very different. Not sure which articles which information should go in though.

Nils von Barth (nbarth) (talk) 00:46, 14 September 2008 (UTC)

The article here (image scaling) only talks about digital images, while I guess that the title can refer to the analog domain as well. So from that image scaling may be the more general and maybe Resampling (bitmap) the more specific article and we should move the detailed descriptions of the digital algorithms and stuff over there - and add something about analog stuff here, of course.--Dvaer (talk) 19:28, 3 October 2010 (UTC)

Proposal: Merge From Bilinear interpolation section on applications to image processing

I believe that the Bilinear interpolation article section on "Applications to Image Processing" should not be merged to the Image scaling article because bilinear interpolation is used in many more image processing operations than just scaling. I, myself, am using it for re-sampling an image from Cartesian to polar coordinates. Others use it for re-sampling for perspective projection or inverse projection in image registration or texture mapping. I have also seen it used where one has a sparse grid of data points and one wishes to interpolate intermediate values -- for example, when one has a coarse grid of optical flow vectors in an image and wishes to interpolate the vector in-between to predict the motion of a pixel whose flow was not measured, one can use a bilinear interpolant for that velocity pair. This can happen in coarse-to fine algorithms like some versions of the Lucas-Kanade optical flow algorithm. Other coarse-to fine algorithms can require interpolation and use bilinear interpolants as well.

Because of this, bilinear interpolation's applications to image processing section cannot be properly merged into Image Scaling, or even image resampling.

A better proposal might be to have an article on applications of interpolation to image processing and list bilinear (along with bicubic, Gaussian, truncated sinc, etc., etc.) as different methods used, preferably with comments on the tradeoffs.

BrotherE (talk) 05:13, 7 March 2009 (UTC)

Thanks – these are very good points, and I’ll work them into relevant articles.

To summarize:

• Resampling is not always scaling – it can also be a change of coordinate system (Cartesian to polar);
• “Resampling” tends to imply “changing a uniform sampling rate”, but it can also be used in interpolation from sparse data, as you mention.

—Nils von Barth (nbarth) (talk) 12:48, 16 April 2009 (UTC)

Yep. This article is detailing a very different beast. I makes perfect sense to stay in its own page. — Kieff | Talk 11:53, 27 February 2011 (UTC)

Zoom...now enhance...

Do you think this article should say something about the "zoom and enhance" thing seen in CSI, etc.? Yes, I know it's impossible in real life, but lots of wiki articles have an "in popular culture" section. 'FLaRN'(talk) 21:50, 1 September 2010 (UTC)

Now that the article has been renamed

I noticed that this article has been moved from Pixel art scaling algorithms to Image scaling. The more general name needs to touch on algorithms intended for continuous tone images such as photographs and high-quality CGI, such as linear, cubic, and sinc resampling. --Damian Yerrick (talk | stalk) 13:28, 13 November 2011 (UTC)

And which is the best?

I want to use one of them in my project. Which is the best? As for me Hqx is the better choice. Your arguments? 178.49.101.206 (talk) 07:50, 10 January 2012 (UTC)Max

Depends on what your project is. Hqx is very processor intensive (compared to the others), so if you are working on something for a mobile device I would shy away from it. (Screen size would diminish the benefit, while limited processor and battery would amplify the downside). If neither of these are constraints, I would lean toward Hqx, so long as whatever you filtering isn't one of the several things Hqx does a poor job of scaling (You'll see it if you encounter it.) If you're not doing an emulator, I'd say you are better off hand-scaling your graphics though. — Preceding unsigned comment added by 98.118.85.79 (talk) 03:15, 7 February 2012 (UTC)

Example Video

The source image used has poorly rendered text, which makes it hard to tell whether or not the output is acceptable or not. Also, the excessive fades make it nearly impossible to tell the difference between each algorithm. Also, algorithm is spelled incorrectly. — Preceding unsigned comment added by 98.118.85.79 (talk) 03:12, 7 February 2012 (UTC)

Split tag

As stated at the top of this page, the section to be split off was in fact recently merged into this article. This would seem to be the correct place for it. The lede says that the article is about digital images, so it is not as if e.g. analogue scaling has been "unfairly" sidelined. The article may well need to be improved, but it does not need to be split. Op47 (talk) 15:28, 20 April 2012 (UTC)

Poor choice example image

The image containing the word "Wiki" already has antialiased edges, which makes it perhaps not as clear as possible where the antialiasing in the example output images comes from. The nearest-neighbour interpolated image, in particular, shows the antialiased edge, but it's really just showing the intermediate-valued pixels that are already in the original. Bernd Jendrissek (talk) 22:01, 10 September 2012 (UTC)

Super 2xSaI and Super Eagle

Which of the sentences extracted from the same paragraph is correct? -> Super Eagle [...] is similar to the 2×SaI engine, but does more blending -> Super 2×SaI [...] blends more than the Super Eagle engine — Preceding unsigned comment added by 201.68.160.227 (talk) 16:51, 22 February 2013 (UTC) It means that Super 2×SaI blends more than Super Eagle, which blends more than 2×SaI. Read correctly. 83.28.255.115 (talk) 19:17, 10 December 2015 (UTC)

Eagle

"Eagle works as follows: for every in pixel we will generate 4 out pixels. First, set all 4 to the colour of the in pixel we are currently scaling (as nearest-neighbor). Next look at the pixels up and to the left; if they are the same colour as each other, set the top left pixel to that colour. Continue doing the same for all four pixels, and then move to the next one."

This is different from the implementation, which checks 3 pixels instead of 2. I assume the pseudo-code is right and the text is incomplete. ? — Preceding unsigned comment added by 190.245.94.186 (talk) 21:56, 25 July 2013 (UTC)

Where's the 2xSaI pseudocode?

Thanks to the lack of information provided by the original uploader, of this article, I am presented with a wonderful pseudocode of the Eagle algorithm, but the 2xSaI algorithm remains left out. I need somebody to post it to Wiki here so I can implement it in a project I'm creating. I tried looking at the C source-code from its creator, but reading that code left my head spinning. Maybe somebody who's a wikipedian and who has significant knowledge of the workings of this specific algorithm can post it up here in this Wiki article for me as simple pseudo code for me so I can implement it in the software I'm writing. Benhut1 (talk) 09:50, 20 September 2014 (UTC)

Poor quality image

The HQ4x fish has very poor quality in the image that compares the original, HQ4x and 4xBRZ. It looks like the image that came from HQ4x has been saved in some lossy format like jpeg before it was enlarged and saved in PNG again. The image need to be updated, or removed, because as it is now it gives the impression that HQ4x is much worse than it really is. 90.227.25.67 (talk) 16:36, 17 January 2015 (UTC)

The poor quality has been fixed and the image has been moved to Pixel art scaling algorithms. Pjeo (talk) 16:45, 8 February 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Image scaling. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20101126091759/http://neuron2.net/library/nedi.pdf to http://neuron2.net/library/nedi.pdf
• Added archive http://web.archive.org/web/20041221052401/http://www.cs.ucdavis.edu:80/~bai/ECS231/finaltzeng.pdf to http://www.cs.ucdavis.edu/~bai/ECS231/finaltzeng.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 06:48, 21 March 2016 (UTC)

De-bloating, and a start on re-writing

The image scaling article had become a bloated mess, mostly devoted to comparison galleries of images produced by a seemingly endless list of various fairly trivial algorithms. I've now de-merged the pixel art stuff into its own article, but too much of this article is still devoted to blow-by-blow comparisons of individual algorithms with inline images that takes up a lot of space to say very little. There is a good article to be written on image scaling, which is a subject with surprisingly deep ramifications into machine vision and the psychophysics of vision, but this isn't yet it. -- The Anome (talk) 10:23, 3 July 2016 (UTC)

Approaches for a reformulation of the article:

• Describe early ad-hoc methods first
• Simple approaches are basically attempts at resampling a two-dimensional band-limited signal
• More complex approaches are basically attempts at the general function approximation problem, which is in turn generally approached (implicity or explicitly) as an inverse problem using knowledge from the universe of real-world images to provide appropriate priors
• We really should mention the use of neural network approaches to the problem, see for example http://ejohn.org/blog/using-waifu2x-to-upscale-japanese-prints/
• Pixel art re-scaling is a specialist topic that, while it fits within this overall framework, needs its own article to go into the many different ad-hoc algorithms that have been developed for this purpose
• See also image reconstruction for the more general problem of which this is a sub-problem

-- The Anome (talk) 10:52, 3 July 2016 (UTC)

Nice, I have wanted to do that myselfCarewolf (talk) 12:47, 3 July 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Image scaling. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20160214121631/http://www.csee.wvu.edu/~xinl/papers/ICIP2000a.pdf to http://www.csee.wvu.edu/~xinl/papers/ICIP2000a.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:02, 12 November 2017 (UTC)

Super resolution vs Resolution enhancement technology

Hello,

Should the resolution enhancement in the third sentence of the introduction ″ In video technology, the magnification of digital material is known as upscaling or resolution enhancement.″ link to, as it currently does, https://en.wikipedia.org/wiki/Resolution_enhancement_technology or wouldn't https://en.wikipedia.org/wiki/Super-resolution_imaging be better?

37.136.2.21 (talk) 10:30, 16 September 2018 (UTC)

Removal of Real-Time Image Scaling Section

I suggest removing the real-time image scaling section that was added under applications. The listed temporal scaling APIs are not applications of any of the image scaling algorithms listed in this article and does not fit here. — Preceding unsigned comment added by 47.208.103.244 (talk) 22:10, 17 May 2022 (UTC)

Adding in that all video upscalers are real-time image scaling solutions. There are many real-time upscaling is not new, or limited to the graphics APIs listed. The scalers in monitors/TVs are real-time upscalers and GPUs have been able to do real time image scaling outside these APIs for decades.

These are APIs to do upscaling of specific graphics elements in the rendering pipeline instead of post processing. 47.208.103.244 (talk) 16:45, 24 May 2022 (UTC)

Just pointing out that this content being removed from this article will not result in the other article being restored, if that's what you're trying to do in a roundabout way. Sergecross73 msg me 17:12, 24 May 2022 (UTC)

Amateurish and completely false article

This article is completely false in its entire concept. It is so wrong that it is hilarious.

"Vector graphics" cannot be scaled at all, because they do not have any intrinsic property related to scale or size. If such a property is artificially added (for example, pixel metrics like setting the image to a certain size x × y), then "image scaling" is performed by simply modifying that property x × y.

There are two basic ways to do image scaling of BITMAPPED graphics:

• (1) Preserve original appearance — e.g., nearest neighbor, bilinear, trilinear, mip-mapping, and other such filters.
• (2) Try to enhance original appearance — e.g., edge-directed methods, neural networks, pixel-art algorithms, etc.

In case (1) the basic dilemma is: what is "original appearance", and, depending on the answer, the actual method varies (is original point-sampled, area-sampled, how much blur did it originally have, did it originally contain frequencies above nyquist or not, etc.).

In case (2) it is about what looks best, usually depending on some properties of the source image or some specific expectation (denoised, sharpened, line detection, shape detection, AI-enhanced to look like other similar images, etc.).

So, from that point of view, you can see how wrong the article is: it completely fails to discuss those points or even mention them. It then mindlessly lists various assorted methods, any well‑known technique an amateur Wikipedia editor has heard of, without explaining why those methods are used. 95.178.146.159 (talk) 14:15, 21 October 2025 (UTC)

Instead of the word "BITMAPPED graphics", which is colloquial, use "raster graphics". Note that "bitmap" doesn't appear in the article; "raster" is mentioned but not used to properly classify the scaling algorithms by the source data they operate on. 95.178.146.159 (talk) 14:34, 21 October 2025 (UTC)

Thinking about it, I would add a prominent banner at the top saying:

"This article is completely false — please improve it by reading the relevant comment on the talk page."

I don't know whether such a banner exists on Wikipedia at all — probably not, since that would be embarrassing and Wikipedia may prefer to hide its amateurism. 95.178.146.159 (talk) 14:48, 21 October 2025 (UTC)

What are you talking about? Vector graphics does have scaling. For instance adding extra details at certain sizes,but this article doesnt discuss scaling vector graphics. The only mention of vector graphics, is turning bitmap images into vector images as a way to make them scalable. While your analysis of bitmap scaling isn't wrong, it doesn't add anything either. Can you find sources talking about it that way? In any case, please keep a polite tone. Carewolf (talk) 09:50, 26 October 2025 (UTC)

Carewolf said: "Vector graphics does have scaling" — that depends on what you mean by 'scaling.' From my point of view, vector graphics are resolution‑independent. To 'scale' them, you don't change the stored coordinates; you change the rendering transformation.

A content creator might apply a coordinate transform to vector graphics, which some may call a form of "scaling". Uses for such transformations are extremely limited. In ordinary practice, vector graphics are not scaled; they are rendered with different output transformations.

Carewolf said: "While your analysis of bitmap scaling isn't wrong, it doesn't add anything either" — I beg to differ. There is a large difference between preserving appearance and enhancing appearance, and that's why the methods for each differ drastically. The omission of that key distinction ruins the entire article.

Carewolf said: "Can you find sources talking about it that way" — Sorry, I'm not paid to work for Wikipedia. Such sources would be hard to find: the issue is trivial and obvious enough that academics rarely state it explicitly, yet confusing enough that amateur websites and online magazines get it wrong almost always. That's precisely why the article is the way it is. 95.178.128.79 (talk) 19:07, 27 October 2025 (UTC)

Here, I used an AI (Duck.ai) to produce suggestions for improving the article, with lots of effort from my side. Here are the results.

Consider presenting two top-level sections, “Appearance preservation” and “Appearance enhancement”, instead of the current mixed list.

Granularity should be standardized by grouping entries into consistent families. For example, treat hqx as “pixel-art upscalers”, Lanczos resampling as “band-limited reconstruction”, and deep convolutional neural networks as “AI-based methods”.

In the "Appearance preservation" section add a short “rendering intent” subsection that notes most image files don’t record which model applies (unspecified rendering intent). “Point-sampled, band-limited” rendering intent is usually inferred.

Finally, the AI produced a compact, intent-first table, grouping "Appearance preservation" methods by rendering intent; that table can serve as a practical decision guide for reorganizing the article.

Intent	When to use	Representative methods
Fast	Realtime, previews, pixel art — speed over fidelity	Nearest, bilinear, trilinear
Point-sampled (band-limited)	Source ≈ ideal samples; preserve detail, avoid aliasing	Lanczos / windowed-sinc, high-order splines
Area-sampled (integral)	Camera/scanner pixels ≈ area integrals; correct downscaling; avoid brightness shifts	Box/area averaging; pyramid downsampling; prefilter low-pass
Scale-aware	Large or progressive reductions across scales	Gaussian/Laplacian pyramids; FFT resampling
Edge-preserve (signal)	Keep geometric edges sharp without semantic changes	Adaptive edge-preserving kernels
Production (efficient + correct)	Deployed systems needing speed + antialiasing	Polyphase / prefiltered separable resamplers
Other point-sampled / non-band-limited	Pixel art; emulate original display	Fast up-scalers then post-blur / CRT filter

95.178.230.184 (talk) 14:01, 31 October 2025 (UTC)