Pixel-art scaling algorithms - Revision history

OAbot: Open access bot: url-access updated in citation with #oabot.

2025-05-25T20:01:39Z

Open access bot: url-access updated in citation with #oabot.

← Previous revision		Revision as of 20:01, 25 May 2025
Line 195:		Line 195:

	=== Kopf–Lischinski ===		=== Kopf–Lischinski ===
	The Kopf–Lischinski algorithm is a novel way to extract resolution-independent [[vector graphics]] from pixel art described in the 2011 paper "Depixelizing Pixel Art".<ref name="pixelart">{{cite journal\|author=Johannes Kopf and Dani Lischinski\|title=Depixelizing pixel art\|journal=ACM Transactions on Graphics\|year=2011\|volume=30\|issue=4\|pages=99:1–99:8\|doi=10.1145/2010324.1964994\|url=http://johanneskopf.de/publications/pixelart/\|publisher=[[SIGGRAPH]]\|access-date=2016-05-22\|archive-date=2016-05-13\|archive-url=https://web.archive.org/web/20160513111621/http://johanneskopf.de/publications/pixelart/\|url-status=live}}</ref> A Python implementation is available.<ref>{{cite web \|last1=Vemula \|first1=Anirudh \|last2=Yeddu \|first2=Vamsidhar \|title=Pixel-Art: We implement the famous "Depixelizing Pixel Art" paper by Kopf and Lischinski \|website=[[GitHub]] \|url=https://github.com/vvanirudh/Pixel-Art \|date=29 April 2019 \|access-date=7 May 2019 \|archive-date=11 June 2018 \|archive-url=https://web.archive.org/web/20180611022300/https://github.com/vvanirudh/Pixel-Art \|url-status=live }}</ref>		The Kopf–Lischinski algorithm is a novel way to extract resolution-independent [[vector graphics]] from pixel art described in the 2011 paper "Depixelizing Pixel Art".<ref name="pixelart">{{cite journal\|author=Johannes Kopf and Dani Lischinski\|title=Depixelizing pixel art\|journal=ACM Transactions on Graphics\|year=2011\|volume=30\|issue=4\|pages=99:1–99:8\|doi=10.1145/2010324.1964994\|url=http://johanneskopf.de/publications/pixelart/\|publisher=[[SIGGRAPH]]\|access-date=2016-05-22\|archive-date=2016-05-13\|archive-url=https://web.archive.org/web/20160513111621/http://johanneskopf.de/publications/pixelart/\|url-status=live\|url-access=subscription}}</ref> A Python implementation is available.<ref>{{cite web \|last1=Vemula \|first1=Anirudh \|last2=Yeddu \|first2=Vamsidhar \|title=Pixel-Art: We implement the famous "Depixelizing Pixel Art" paper by Kopf and Lischinski \|website=[[GitHub]] \|url=https://github.com/vvanirudh/Pixel-Art \|date=29 April 2019 \|access-date=7 May 2019 \|archive-date=11 June 2018 \|archive-url=https://web.archive.org/web/20180611022300/https://github.com/vvanirudh/Pixel-Art \|url-status=live }}</ref>

	The algorithm has been ported to GPUs and optimized for real-time rendering. The [[source code]] is available for this variant.<ref>{{cite book \|last1=Kreuzer \|first1=Felix \|last2=Kopf \|first2=Johannes \|last3=Wimmer \|first3=Michael \|title=Proceedings of the 19th Symposium on Interactive 3D Graphics and Games \|chapter=Depixelizing pixel art in real-time \|date=2015 \|pages=130 \|doi=10.1145/2699276.2721395 \|chapter-url=https://www.cg.tuwien.ac.at/research/publications/2015/KREUZER-2015-DPA \|publisher=ACM \|isbn=9781450333924 \|s2cid=7592555 \|access-date=2019-05-07 \|archive-date=2019-05-07 \|archive-url=https://web.archive.org/web/20190507061859/https://www.cg.tuwien.ac.at/research/publications/2015/KREUZER-2015-DPA/ \|url-status=live }}</ref>		The algorithm has been ported to GPUs and optimized for real-time rendering. The [[source code]] is available for this variant.<ref>{{cite book \|last1=Kreuzer \|first1=Felix \|last2=Kopf \|first2=Johannes \|last3=Wimmer \|first3=Michael \|title=Proceedings of the 19th Symposium on Interactive 3D Graphics and Games \|chapter=Depixelizing pixel art in real-time \|date=2015 \|pages=130 \|doi=10.1145/2699276.2721395 \|chapter-url=https://www.cg.tuwien.ac.at/research/publications/2015/KREUZER-2015-DPA \|publisher=ACM \|isbn=9781450333924 \|s2cid=7592555 \|access-date=2019-05-07 \|archive-date=2019-05-07 \|archive-url=https://web.archive.org/web/20190507061859/https://www.cg.tuwien.ac.at/research/publications/2015/KREUZER-2015-DPA/ \|url-status=live }}</ref>

StainedGlassCavern: /* hqnx family */ disambiguate

2025-01-22T16:50:36Z

hqnx family: disambiguate

← Previous revision		Revision as of 16:50, 22 January 2025
Line 158:		Line 158:

	=== hq''n''x family ===		=== hq''n''x family ===
	{{main\|hqx}}		{{main\|hqx (algorithm)}}
	[[Maxim Stepin]]'s hq2x, hq3x, and hq4x are for scale factors of 2:1, 3:1, and 4:1 respectively. Each work by comparing the color value of each pixel to those of its eight immediate neighbors, marking the neighbors as close or distant, and using a pre-generated lookup table to find the proper proportion of input pixels' values for each of the 4, 9 or 16 corresponding output pixels. The hq3x family will perfectly smooth any diagonal line whose slope is ±0.5, ±1, or ±2 and which is not anti-aliased in the input; one with any other slope will alternate between two slopes in the output. It will also smooth very tight curves. Unlike 2xSaI, it anti-aliases the output.<ref>{{ cite web \| last = Stepin \| first = Maxim \| url = http://www.hiend3d.com/hq3x.html \| title = hq3x Magnification Filter \| access-date = 2007-07-03 \| url-status = dead \| archive-url = https://web.archive.org/web/20070703061942/http://www.hiend3d.com/hq3x.html \| archive-date = 2007-07-03 }}</ref><ref name="pixelscalers" />		Maxim Stepin's hq2x, hq3x, and hq4x are for scale factors of 2:1, 3:1, and 4:1 respectively. Each work by comparing the color value of each pixel to those of its eight immediate neighbors, marking the neighbors as close or distant, and using a pre-generated lookup table to find the proper proportion of input pixels' values for each of the 4, 9 or 16 corresponding output pixels. The hq3x family will perfectly smooth any diagonal line whose slope is ±0.5, ±1, or ±2 and which is not anti-aliased in the input; one with any other slope will alternate between two slopes in the output. It will also smooth very tight curves. Unlike 2xSaI, it anti-aliases the output.<ref>{{ cite web \| last = Stepin \| first = Maxim \| url = http://www.hiend3d.com/hq3x.html \| title = hq3x Magnification Filter \| access-date = 2007-07-03 \| url-status = dead \| archive-url = https://web.archive.org/web/20070703061942/http://www.hiend3d.com/hq3x.html \| archive-date = 2007-07-03 }}</ref><ref name="pixelscalers" />

	{{Gallery		{{Gallery

Lord Nightmare: fix accidental "vandalism" by wikicleanerbot where it mis-recognized part of a diagram as an empty list item

2024-10-02T01:41:23Z

fix accidental "vandalism" by wikicleanerbot where it mis-recognized part of a diagram as an empty list item

← Previous revision		Revision as of 01:41, 2 October 2024
Line 31:		Line 31:
	The degenerate case:		The degenerate case:
	<pre>		<pre>
	*		*
	* *		* *
	*		*
	</pre>		</pre>
	becomes:		becomes:
	<pre>		<pre>
	**		**
	****		****
			******

	****		******
	**		****
			**
	</pre>		</pre>

Georgebrown5566: /* Edge-directed interpolation (EDI) */ minor grammar changes

2024-08-22T07:21:19Z

Edge-directed interpolation (EDI): minor grammar changes

← Previous revision		Revision as of 07:21, 22 August 2024
Line 200:		Line 200:
	=== Edge-directed interpolation (EDI) ===		=== Edge-directed interpolation (EDI) ===
	{{tone\|section\|date=May 2016}}		{{tone\|section\|date=May 2016}}
	Edge-directed interpolation (EDI) describes upscaling techniques that use statistical sampling to ensure the quality of an image ~~when scaling~~ it up.<ref>{{Cite web\|url=http://chiranjivi.tripod.com/EDITut.html\|title=Edge-Directed Interpolation\|website=chiranjivi.tripod.com\|access-date=2019-05-07\|archive-date=2016-02-25\|archive-url=https://web.archive.org/web/20160225134822/http://chiranjivi.tripod.com/EDITut.html\|url-status=live}}</ref><ref>{{Cite web\|url=https://forum.doom9.org/showthread.php?s=7fb2fb184cfe82b7d76b63bb26df481a&t=170727\|title=Shader implementation of the NEDI algorithm - Doom9's Forum\|website=forum.doom9.org\|access-date=2019-05-07\|archive-date=2022-05-13\|archive-url=https://web.archive.org/web/20220513124234/https://forum.doom9.org/showthread.php?s=7fb2fb184cfe82b7d76b63bb26df481a&t=170727\|url-status=live}}</ref> There were several earlier methods that involved detecting edges to generate blending weights for linear interpolation or classifying pixels according to their neighbor conditions and using different otherwise isotropic interpolation schemes based on the classification.		Edge-directed interpolation (EDI) describes upscaling techniques that use statistical sampling to ensure the quality of an image as it is scaled up.<ref>{{Cite web\|url=http://chiranjivi.tripod.com/EDITut.html\|title=Edge-Directed Interpolation\|website=chiranjivi.tripod.com\|access-date=2019-05-07\|archive-date=2016-02-25\|archive-url=https://web.archive.org/web/20160225134822/http://chiranjivi.tripod.com/EDITut.html\|url-status=live}}</ref><ref>{{Cite web\|url=https://forum.doom9.org/showthread.php?s=7fb2fb184cfe82b7d76b63bb26df481a&t=170727\|title=Shader implementation of the NEDI algorithm - Doom9's Forum\|website=forum.doom9.org\|access-date=2019-05-07\|archive-date=2022-05-13\|archive-url=https://web.archive.org/web/20220513124234/https://forum.doom9.org/showthread.php?s=7fb2fb184cfe82b7d76b63bb26df481a&t=170727\|url-status=live}}</ref> There were several earlier methods that involved detecting edges to generate blending weights for linear interpolation or classifying pixels according to their neighbor conditions and using different otherwise isotropic interpolation schemes based on the classification.
	~~Any given~~ interpolation approach boils down to weighted averages of neighboring pixels. The goal is to find optimal weights. [[Bilinear interpolation]] sets all the weights to be equal. Higher-order interpolation methods ~~like~~ [[bicubic interpolation\|bicubic]] or [[sinc interpolation]] consider a larger number of neighbors than just the adjacent ones.		Each interpolation approach boils down to weighted averages of neighboring pixels. The goal is to find the optimal weights. [[Bilinear interpolation]] sets all the weights to be equal. Higher-order interpolation methods such as [[bicubic interpolation\|bicubic]] or [[sinc interpolation]] consider a larger number of neighbors than just the adjacent ones.

	==== NEDI ====		==== NEDI ====
	NEDI (New Edge-Directed Interpolation) computes local covariances in the original image and uses them to adapt the interpolation at high resolution. It is the ~~prototypic~~ filter of this family.<ref name=":0" />		NEDI (New Edge-Directed Interpolation) computes local covariances in the original image and uses them to adapt the interpolation at high resolution. It is the prototype filter of this family.<ref name=":0" />

	==== EDIUpsizer ====		==== EDIUpsizer ====
Line 222:		Line 222:

	==== NNEDI ====		==== NNEDI ====
	NNEDI is a family of intra-field [[Deinterlacing\|deinterlacers]] ~~which~~ can also be used to ~~enlarge~~ images by powers of two. When being used as a deinterlacer, it takes in a [[Film frame\|frame]], throws away one [[Field (video)\|field]], and then interpolates the missing pixels using only information from the kept field. There are so far three major generations of NNEDI.		NNEDI is a family of intra-field [[Deinterlacing\|deinterlacers]] that can also be used for enlarging images by powers of two. When being used as a deinterlacer, it takes in a [[Film frame\|frame]], throws away one [[Field (video)\|field]], and then interpolates the missing pixels using only the information from the kept field. There are so far three major generations of NNEDI.

	NNEDI, the original version, works with [[YUY2]] and [[YV12]] input.<ref>{{cite web\|url=http://forum.doom9.org/showthread.php?t=129953\|title=NNEDI - intra-field deinterlacing filter - Doom9's Forum\|access-date=19 February 2016\|archive-date=2 March 2016\|archive-url=https://web.archive.org/web/20160302100745/http://forum.doom9.org/showthread.php?t=129953\|url-status=live}}</ref> NNEDI2 added RGB24 support and a special function <code>nnedi2_rpow2</code> for upscaling. NNEDI3 ~~enhances~~ NNEDI2 with a predictor [[neural network]]. Both the size of the network and the neighborhood it examines can be ~~tweaked~~ for a speed-quality tradeoff:<ref>{{Cite web\|url=http://avisynth.nl/index.php/Nnedi3\|title=Nnedi3\|website=AviSynth\|access-date=2019-05-07\|archive-date=2019-05-07\|archive-url=https://web.archive.org/web/20190507054547/http://avisynth.nl/index.php/Nnedi3\|url-status=live}}</ref><blockquote>This is a quality vs speed option; however, differences are usually small between the number of neurons for a specific resize factor, however the performance difference between the count of neurons becomes larger as you quadruple the image size. If you are only planning on doubling the resolution then you won't see massive differences between 16 and 256 neurons. There is still a noticeable difference between the highest and lowest options, but not orders of magnitude different.<ref>{{Citation\|last=tritical\|title=nnedi3 - Readme.txt\|date=2019-04-30\|url=https://github.com/jpsdr/NNEDI3\|access-date=2019-05-07\|archive-date=2019-04-17\|archive-url=https://web.archive.org/web/20190417055010/https://github.com/jpsdr/NNEDI3\|url-status=live}}</ref></blockquote>		NNEDI, the original version, works with [[YUY2]] and [[YV12]] input.<ref>{{cite web\|url=http://forum.doom9.org/showthread.php?t=129953\|title=NNEDI - intra-field deinterlacing filter - Doom9's Forum\|access-date=19 February 2016\|archive-date=2 March 2016\|archive-url=https://web.archive.org/web/20160302100745/http://forum.doom9.org/showthread.php?t=129953\|url-status=live}}</ref> NNEDI2 added RGB24 support and a special function <code>nnedi2_rpow2</code> for upscaling. NNEDI3 extends NNEDI2 with a predictor [[neural network]]. Both the size of the network and the neighborhood it examines can be tuned for a speed-quality tradeoff:<ref>{{Cite web\|url=http://avisynth.nl/index.php/Nnedi3\|title=Nnedi3\|website=AviSynth\|access-date=2019-05-07\|archive-date=2019-05-07\|archive-url=https://web.archive.org/web/20190507054547/http://avisynth.nl/index.php/Nnedi3\|url-status=live}}</ref><blockquote>This is a quality vs speed option; however, differences are usually small between the number of neurons for a specific resize factor, however the performance difference between the count of neurons becomes larger as you quadruple the image size. If you are only planning on doubling the resolution then you won't see massive differences between 16 and 256 neurons. There is still a noticeable difference between the highest and lowest options, but not orders of magnitude different.<ref>{{Citation\|last=tritical\|title=nnedi3 - Readme.txt\|date=2019-04-30\|url=https://github.com/jpsdr/NNEDI3\|access-date=2019-05-07\|archive-date=2019-04-17\|archive-url=https://web.archive.org/web/20190417055010/https://github.com/jpsdr/NNEDI3\|url-status=live}}</ref></blockquote>

	== References ==		== References ==

BugBear2: linked ROM to the page of 'rad-only memory'

2024-08-08T14:05:03Z

linked ROM to the page of 'rad-only memory'

← Previous revision		Revision as of 14:05, 8 August 2024
Line 13:		Line 13:

	=== SAA5050 'Diagonal Smoothing' ===		=== SAA5050 'Diagonal Smoothing' ===
	The [[Mullard SAA5050]] Teletext character generator chip (1980) used a primitive pixel scaling algorithm to generate higher-resolution characters on the screen from a lower-resolution representation from its internal ROM. Internally, each character shape was defined on a {{resx\|5x9}} pixel grid, which was then interpolated by smoothing diagonals to give a {{resx\|10x18}} pixel character, with a characteristically angular shape, surrounded to the top and the left by two pixels of blank space. The algorithm only works on monochrome source data, and assumes the source pixels will be logically true or false depending on whether they are 'on' or 'off'. Pixels 'outside the grid pattern' are assumed to be off.<ref>{{cite web \|url=https://amigan.yatho.com/saa5050.pdf \|title=Mullard SAA5050 Datasheet \|access-date=2018-11-12 \|archive-date=2017-06-19 \|archive-url=https://web.archive.org/web/20170619025049/http://amigan.yatho.com/saa5050.pdf \|url-status=dead }}</ref><ref>{{cite web \|url=https://github.com/mamedev/mame/blob/master/src/devices/video/saa5050.cpp#L445 \|title=SAA5050 Smoothing source code from the MAME project \|website=[[GitHub]] \|date=6 November 2022 \|access-date=12 November 2018 \|archive-date=13 August 2023 \|archive-url=https://web.archive.org/web/20230813180715/https://github.com/mamedev/mame/blob/master/src/devices/video/saa5050.cpp#L445 \|url-status=live }}</ref><ref>{{cite web \|url=https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=102137#Post102137 \|title=Forum post showing Teletext reference test page on SAA5050 chip \|access-date=2018-11-12 \|archive-date=2018-11-13 \|archive-url=https://web.archive.org/web/20181113025514/https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=102137#Post102137 \|url-status=live }}</ref>		The [[Mullard SAA5050]] Teletext character generator chip (1980) used a primitive pixel scaling algorithm to generate higher-resolution characters on the screen from a lower-resolution representation from its internal [[Read-only memory\|ROM]]. Internally, each character shape was defined on a {{resx\|5x9}} pixel grid, which was then interpolated by smoothing diagonals to give a {{resx\|10x18}} pixel character, with a characteristically angular shape, surrounded to the top and the left by two pixels of blank space. The algorithm only works on monochrome source data, and assumes the source pixels will be logically true or false depending on whether they are 'on' or 'off'. Pixels 'outside the grid pattern' are assumed to be off.<ref>{{cite web \|url=https://amigan.yatho.com/saa5050.pdf \|title=Mullard SAA5050 Datasheet \|access-date=2018-11-12 \|archive-date=2017-06-19 \|archive-url=https://web.archive.org/web/20170619025049/http://amigan.yatho.com/saa5050.pdf \|url-status=dead }}</ref><ref>{{cite web \|url=https://github.com/mamedev/mame/blob/master/src/devices/video/saa5050.cpp#L445 \|title=SAA5050 Smoothing source code from the MAME project \|website=[[GitHub]] \|date=6 November 2022 \|access-date=12 November 2018 \|archive-date=13 August 2023 \|archive-url=https://web.archive.org/web/20230813180715/https://github.com/mamedev/mame/blob/master/src/devices/video/saa5050.cpp#L445 \|url-status=live }}</ref><ref>{{cite web \|url=https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=102137#Post102137 \|title=Forum post showing Teletext reference test page on SAA5050 chip \|access-date=2018-11-12 \|archive-date=2018-11-13 \|archive-url=https://web.archive.org/web/20181113025514/https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=102137#Post102137 \|url-status=live }}</ref>

	The algorithm works as follows:		The algorithm works as follows:

Scg9404: Grammar and readability

2024-07-14T21:32:07Z

Grammar and readability

← Previous revision		Revision as of 21:32, 14 July 2024
Line 8:		Line 8:
	These specialized algorithms can improve the appearance of pixel-art graphics, but in doing so they introduce changes. Such changes may be undesirable, especially if the goal is to faithfully reproduce the original appearance.		These specialized algorithms can improve the appearance of pixel-art graphics, but in doing so they introduce changes. Such changes may be undesirable, especially if the goal is to faithfully reproduce the original appearance.

	Since a typical application of this technology is improving the appearance of [[history of video game consoles (fourth generation)\|fourth-generation]] and earlier [[video game]]s on [[video game console emulator\|arcade and console emulators]], many pixel art scaling algorithms are designed to run in real-time for sufficiently small input images at 60-[[frames per second]]. This places constraints on the type of [[computer programming\|programming]] techniques that can be used for this sort of real-time processing.{{citation needed\|date=June 2023\|reason=Unclear what constraints this refers to as scaling algorithms can usually be parallelized and the source resolution would be low.}} Many work only on specific scale factors~~, with~~ 2× ~~being~~ the most ~~commonly~~ ~~used~~ and 3×, 4×, 5×, and 6× less used.		Since a typical application of this technology is improving the appearance of [[history of video game consoles (fourth generation)\|fourth-generation]] and earlier [[video game]]s on [[video game console emulator\|arcade and console emulators]], many pixel art scaling algorithms are designed to run in real-time for sufficiently small input images at 60-[[frames per second]]. This places constraints on the type of [[computer programming\|programming]] techniques that can be used for this sort of real-time processing.{{citation needed\|date=June 2023\|reason=Unclear what constraints this refers to as scaling algorithms can usually be parallelized and the source resolution would be low.}} Many work only on specific scale factors. 2× is the most common scale factor, while and 3×, 4×, 5×, and 6× exist but are less used.

	== Algorithms ==		== Algorithms ==
Line 191:		Line 191:

	==== Fast RotSprite ====		==== Fast RotSprite ====
	Fast RotSprite is a fast rotation algorithm for pixel art developed by Oleg Mekekechko for [https://play.google.com/store/apps/details?id=com.PixelStudio Pixel Studio] app. It is based on [[#RotSprite\|RotSprite]] but has better performance with slight quality loss. It can process larger images in real-time. Instead of the 8× upscale, Fast RotSprite uses a single 3× upscale. Then it simply rotates all pixels with rounding coordinates. Finally, it performs 3× downscale without introducing new colors. As all operations on each step are independent, they can be done in parallel to greatly increase performance.		Fast RotSprite is a fast rotation algorithm for pixel art developed by Oleg Mekekechko for the [https://play.google.com/store/apps/details?id=com.PixelStudio Pixel Studio] app. It is based on [[#RotSprite\|RotSprite]] but has better performance with slight quality loss. It can process larger images in real-time. Instead of the 8× upscale, Fast RotSprite uses a single 3× upscale. Then it simply rotates all pixels with rounding coordinates. Finally, it performs 3× downscale without introducing new colors. As all operations on each step are independent, they can be done in parallel to greatly increase performance.

	=== Kopf–Lischinski ===		=== Kopf–Lischinski ===

Kamyab xd: Fix spelling, grammar, and tone

2024-07-01T09:42:30Z

Fix spelling, grammar, and tone

Show changes

Cloudberry Jelly: Minor readability improvements in a single paragraph.

2024-06-20T11:20:19Z

Minor readability improvements in a single paragraph.

← Previous revision		Revision as of 11:20, 20 June 2024
Line 6:		Line 6:
	As pixel art graphics are commonly used at very low [[Image resolution\|resolution]]s, they employ careful coloring of individual pixels. This results in graphics that rely on a high amount of stylized visual cues to define complex shapes. A number of specialized algorithms<ref>{{cite web\|url=http://www.datagenetics.com/blog/december32013/index.html\|title=Pixel Scalers\|access-date=19 February 2016\|archive-date=2 March 2016\|archive-url=https://web.archive.org/web/20160302044644/http://www.datagenetics.com/blog/december32013/index.html\|url-status=live}}</ref> have been developed to handle re-scaling of such graphics.		As pixel art graphics are commonly used at very low [[Image resolution\|resolution]]s, they employ careful coloring of individual pixels. This results in graphics that rely on a high amount of stylized visual cues to define complex shapes. A number of specialized algorithms<ref>{{cite web\|url=http://www.datagenetics.com/blog/december32013/index.html\|title=Pixel Scalers\|access-date=19 February 2016\|archive-date=2 March 2016\|archive-url=https://web.archive.org/web/20160302044644/http://www.datagenetics.com/blog/december32013/index.html\|url-status=live}}</ref> have been developed to handle re-scaling of such graphics.

	~~While the~~ specialized algorithms ~~may~~ improve the appearance of pixel-art graphics, ~~they~~ ~~are~~ ~~also~~ ~~changing~~ ~~the~~ ~~appearance~~ ~~of the graphics~~. Such a ~~consequence~~ is undesirable ~~in many situations~~, especially if the goal is to faithfully reproduce the original appearance.		These specialized algorithms can improve the appearance of pixel-art graphics, but in doing so they introduce changes. Such changes may be undesirable, especially if the goal is to faithfully reproduce the original appearance.

	Since a typical application of this technology is improving the appearance of [[history of video game consoles (fourth generation)\|fourth-generation]] and earlier [[video game]]s on [[video game console emulator\|arcade and console emulators]], many pixel art scaling algorithms are designed to run in real time for sufficiently small input images at 60-[[frames per second]]. This places constraints on the type of [[computer programming\|programming]] techniques that can be used for this sort of real-time processing.{{citation needed\|date=June 2023\|reason=Unclear what constraints this refers to as scaling algorithms can usually be parallelized and the source resolution would be low.}} Many work only on specific scale factors, with 2× being the most commonly used and 3×, 4×, 5×, and 6× less used.		Since a typical application of this technology is improving the appearance of [[history of video game consoles (fourth generation)\|fourth-generation]] and earlier [[video game]]s on [[video game console emulator\|arcade and console emulators]], many pixel art scaling algorithms are designed to run in real time for sufficiently small input images at 60-[[frames per second]]. This places constraints on the type of [[computer programming\|programming]] techniques that can be used for this sort of real-time processing.{{citation needed\|date=June 2023\|reason=Unclear what constraints this refers to as scaling algorithms can usually be parallelized and the source resolution would be low.}} Many work only on specific scale factors, with 2× being the most commonly used and 3×, 4×, 5×, and 6× less used.

WikiCleanerBot: v2.05b - Bot T18 CW#553 - Fix errors for CW project ( tags - Title linked in text - Empty list item)

2024-06-17T22:10:19Z

v2.05b - Bot T18 CW#553 - Fix errors for CW project (<nowiki> tags - Title linked in text - Empty list item)

← Previous revision		Revision as of 22:10, 17 June 2024
Line 2:		Line 2:
	[[File:2xsai example.svg\|thumb\|upright=1.4\|Sprite of a television set (center) resized using simple nearest-neighbor scaling (left) and the 2xSaI interpolation algorithm (right)]]		[[File:2xsai example.svg\|thumb\|upright=1.4\|Sprite of a television set (center) resized using simple nearest-neighbor scaling (left) and the 2xSaI interpolation algorithm (right)]]
	[[File:Pixel-Art_Scaling_Comparison.png\|thumb\|upright=1.4\|Comparison of common pixel art scaling algorithms. View in full resolution to see the differences.]]		[[File:Pixel-Art_Scaling_Comparison.png\|thumb\|upright=1.4\|Comparison of common pixel art scaling algorithms. View in full resolution to see the differences.]]
	'''Pixel art scaling algorithms''' are graphical filters that attempt to enhance the appearance of hand-drawn 2D [[pixel art]] graphics. These [[algorithm]]~~<nowiki/>~~s are a form of automatic image enhancement. Pixel art scaling algorithms employ methods significantly different than the common methods of [[image rescaling]], which have the goal of preserving the appearance of images.		'''Pixel art scaling algorithms''' are graphical filters that attempt to enhance the appearance of hand-drawn 2D [[pixel art]] graphics. These [[algorithm]]s are a form of automatic image enhancement. Pixel art scaling algorithms employ methods significantly different than the common methods of [[image rescaling]], which have the goal of preserving the appearance of images.

	As pixel art graphics are commonly used at very low [[Image resolution\|resolution]]s, they employ careful coloring of individual pixels. This results in graphics that rely on a high amount of stylized visual cues to define complex shapes. A number of specialized algorithms<ref>{{cite web\|url=http://www.datagenetics.com/blog/december32013/index.html\|title=Pixel Scalers\|access-date=19 February 2016\|archive-date=2 March 2016\|archive-url=https://web.archive.org/web/20160302044644/http://www.datagenetics.com/blog/december32013/index.html\|url-status=live}}</ref> have been developed to handle re-scaling of such graphics.		As pixel art graphics are commonly used at very low [[Image resolution\|resolution]]s, they employ careful coloring of individual pixels. This results in graphics that rely on a high amount of stylized visual cues to define complex shapes. A number of specialized algorithms<ref>{{cite web\|url=http://www.datagenetics.com/blog/december32013/index.html\|title=Pixel Scalers\|access-date=19 February 2016\|archive-date=2 March 2016\|archive-url=https://web.archive.org/web/20160302044644/http://www.datagenetics.com/blog/december32013/index.html\|url-status=live}}</ref> have been developed to handle re-scaling of such graphics.
Line 39:		Line 39:
	**		**
	****		****

	******
	******
	****		****
	**		**
Line 192:		Line 191:

	==== Fast RotSprite ====		==== Fast RotSprite ====
	Fast RotSprite is a fast rotation algorithm for pixel art developed by Oleg Mekekechko for [https://play.google.com/store/apps/details?id=com.PixelStudio Pixel Studio] app. It is based on [[~~Pixel-art scaling algorithms~~#RotSprite\|RotSprite]] but has better performance with slight quality loss. It is able to process larger images in realtime. Instead of the 8× upscale, Fast RotSprite uses single 3× upscale. Then it simply rotates all pixels with rounding coordinates. Finally, it performs 3× downscale without introducing new colors. As all operations on each step are independent, they can be done in parallel to greatly increase performance.		Fast RotSprite is a fast rotation algorithm for pixel art developed by Oleg Mekekechko for [https://play.google.com/store/apps/details?id=com.PixelStudio Pixel Studio] app. It is based on [[#RotSprite\|RotSprite]] but has better performance with slight quality loss. It is able to process larger images in realtime. Instead of the 8× upscale, Fast RotSprite uses single 3× upscale. Then it simply rotates all pixels with rounding coordinates. Finally, it performs 3× downscale without introducing new colors. As all operations on each step are independent, they can be done in parallel to greatly increase performance.

	=== Kopf–Lischinski ===		=== Kopf–Lischinski ===

Artoria2e5: /* 2×SaI */ comment on complex mask thing

2024-05-17T16:28:05Z

2×SaI: comment on complex mask thing

← Previous revision		Revision as of 16:28, 17 May 2024
Line 129:		Line 129:

	<pre>		<pre>
	INTERPOLATE(uint32 A, UINT32 B)		INTERPOLATE(uint32 A, UINT32 B).
			-- linear midpoint of A and B
	if (A == B) return A;		if (A == B) return A;
	return (		return (
Line 137:		Line 138:

	Q_INTERPOLATE(uint32 A, uint32 B, uint32 C, uint32 D)		Q_INTERPOLATE(uint32 A, uint32 B, uint32 C, uint32 D)
			-- bilinear interpolation; A, B, C, D's average
	x = ((A & qColorMask) >> 2)		x = ((A & qColorMask) >> 2)
	+ ((B & qColorMask) >> 2)		+ ((B & qColorMask) >> 2)