词条 | Pixel-art scaling algorithms |
释义 |
Pixel-art scaling algorithms are graphical filters that are often used in video game emulators to enhance hand-drawn 2D pixel art graphics. The re-scaling of pixel art is a specialist sub-field of image rescaling. As pixel-art graphics are usually in very low resolutions, they rely on careful placing of individual pixels, often with a limited palette of colors. This results in graphics that rely on a high amount of stylized visual cues to define complex shapes with very little resolution, down to individual pixels. This makes image scaling of pixel art a particularly difficult problem. A number of specialized algorithms[1] have been developed to handle pixel-art graphics, as the traditional scaling algorithms do not take such perceptual cues into account. Since a typical application of this technology is improving the appearance of fourth-generation and earlier video games on arcade and console emulators, many are designed to run in real time for sufficiently small input images at 60 frames per second. This places constraints on the type of programming techniques that can be used for this sort of real-time processing. Many work only on specific scale factors: 2× is the most common, with 3×, 4×, 5× and 6× also present. AlgorithmsSAA5050 'diagonal smoothing'The Mullard SAA5050 Teletext character generator chip (1980) used a primitive pixel scaling algorithm to generate higher-resolution characters on screen from a lower-resolution representation from its internal ROM. Internally each character shape was defined on a 5×9 pixel grid, which was then interpolated by smoothing diagonals to give a 10×18 pixel character, with a characteristically angular shape, surrounded to the top and to the left by two pixels of blank space. The algorithm only works on monochrome source data, and assumes the source pixels will be logical true or false depending on whether they are 'on' or 'off'. Pixels 'outside the grid pattern' are assumed to be off.[2][3][4] The algorithm works as follows: A B C --\\ 1 2D E F --/ 3 41 = B | (A & E & !B & !D)2 = B | (C & E & !B & !F)3 = E | (!A & !E & B & D)4 = E | (!C & !E & B & F) Note that this algorithm, like the Eagle algorithm below, has a flaw: If a pattern of 4 pixels in a hollow diamond shape appears, the hollow will be obliterated by the expansion. The SAA5050's internal character ROM carefully avoids ever using this pattern. The degenerate case: ** * *becomes: ** **** ************ **** ** EPX/Scale2×/AdvMAME2×{{anchor|EPX}}Eric's Pixel Expansion (EPX) is an algorithm developed by Eric Johnston at LucasArts around 1992, when porting the SCUMM engine games from the IBM PC (which ran at 320×200×256 colors) to the early color Macintosh computers, which ran at more or less double that resolution.[5] The algorithm works as follows, expanding P into 4 new pixels based on P's surroundings: 1=P; 2=P; 3=P; 4=P; IF C==A => 1=A IF A==B => 2=B IF D==C => 3=C IF B==D => 4=D IF of A, B, C, D, three or more are identical: 1=2=3=4=P Later implementations of this same algorithm (as AdvMAME2× and Scale2×, developed around 2001) have a slightly more efficient but functionally identical implementation: 1=P; 2=P; 3=P; 4=P; IF C==A AND C!=D AND A!=B => 1=A IF A==B AND A!=C AND B!=D => 2=B IF D==C AND D!=B AND C!=A => 3=C IF B==D AND B!=A AND D!=C => 4=D AdvMAME2× is available in DOSBox via the The AdvMAME4×/Scale4× algorithm is just EPX applied twice to get 4× resolution. Scale3×/AdvMAME3× and ScaleFXThe AdvMAME3×/Scale3× algorithm(available in DOSBox via the 1=E; 2=E; 3=E; 4=E; 5=E; 6=E; 7=E; 8=E; 9=E; IF D==B AND D!=H AND B!=F => 1=D IF (D==B AND D!=H AND B!=F AND E!=C) OR (B==F AND B!=D AND F!=H AND E!=A) => 2=B IF B==F AND B!=D AND F!=H => 3=F IF (H==D AND H!=F AND D!=B AND E!=A) OR (D==B AND D!=H AND B!=F AND E!=G) => 4=D 5=E IF (B==F AND B!=D AND F!=H AND E!=I) OR (F==H AND F!=B AND H!=D AND E!=C) => 6=F IF H==D AND H!=F AND D!=B => 7=D IF (F==H AND F!=B AND H!=D AND E!=G) OR (H==D AND H!=F AND D!=B AND E!=I) => 8=H IF F==H AND F!=B AND H!=D => 9=F There is also a variant improved over Scale3× called ScaleFX, developed by Sp00kyFox, and a version combined with Reverse-AA called ScaleFX-Hybrid.[6][7] Eagle{{quote|Eagle works as follows: for every in pixel we will generate 4 out pixels. First, set all 4 to the color of the in pixel we are currently scaling (as nearest-neighbor). Next look at the three pixels above, to the left, and diagonally above left: if all three are the same color as each other, set the top left pixel of our output square to that color in preference to the nearest-neighbor color. Work similarly for all four pixels, and then move to the next one.[8]}}Assume an input matrix of 3×3 pixels where the center most pixel is the pixel to be scaled, and an output matrix of 2×2 pixels (i.e., the scaled pixel) first: |Then. . . --\\ CC |S T U --\\ 1 2. C . --/ CC |V C W --/ 3 4. . . |X Y Z | IF V==S==T => 1=S | IF T==U==W => 2=U | IF V==X==Y => 3=X | IF W==Z==Y => 4=Z Thus if we have a single black pixel on a white background it will vanish. This is a bug in the Eagle algorithm, but is solved by other algorithms such as EPX, 2xSaI and HQ2x. 2×SaI2×SaI, short for 2× Scale and Interpolation engine, was inspired by Eagle. It was designed by Derek Liauw Kie Fa, also known as Kreed, primarily for use in console and computer emulators, and it has remained fairly popular in this niche. Many of the most popular emulators, including ZSNES and VisualBoyAdvance, offer this scaling algorithm as a feature. Since Kreed released[9] the source code under the GNU General Public License, it is freely available to anyone wishing to utilize it in a project released under that license. Developers wishing to use it in a non-GPL project would be required to rewrite the algorithm without using any of Kreed's existing code. It is available in DosBox via Super 2×SaI and Super EagleSeveral slightly different versions of the scaling algorithm are available, and these are often referred to as Super 2×SaI and Super Eagle. Super Eagle, which is also written by Kreed, is similar to the 2×SaI engine, but does more blending. Super 2×SaI, which is also written by Kreed, is a filter that smooths the graphics, but it blends more than the Super Eagle engine. hqnx family{{main article|hqx}}Maxim Stepin's hq2x, hq3x, and hq4x are for scale factors of 2:1, 3:1, and 4:1 respectively. Each works by comparing the color value of each pixel to those of its eight immediate neighbours, marking the neighbours as close or distant, and using a pregenerated 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.[10] Shader long thought to be hqx was in fact another shader of lower quality called HqFilter/ScaleHQ.[11] True hqx[12] has comparable quality to the early versions of xBR. {{Gallery|align=center |width=384 |File:Test nn.png |Image enlarged 3× with the nearest-neighbor interpolation |File:Test hq3x.png |Image enlarged by 3× with hq3x algorithm }}{{clear}} hqnx was initially created for the Super Nintendo emulator ZSNES. The author of bsnes has released a space-efficient implementation of hq2x (ScaleHQ) to the public domain.[13] xBR familyThere are 6 filters in this family: xBR , xBRZ, xBR-Hybrid, Super xBR, xBR+3D and Super xBR+3D. xBR,[14] created by Hyllian, works much the same way as HQx (based on pattern recognition), and would generate the same result as HQx when given the above pattern. However, it goes further than HQx by using a 2-stage set of interpolation rules, which better handle more complex patterns such as anti-aliased lines and curves. Scaled background textures keep the sharp characteristics of the original image, rather than becoming blurred like HQx(In reality ScaleHQ) tends to do. Newest xBR versions are multi-pass and can preserve small details better. There is also a version of xBR combined with Reverse-AA shader called xBR-Hybrid.[15] xBR+3D is a version with a 3D mask that only filters 2D elements. xBRZ,[16] is a modified version of xBR, created by Zenju and implemented from scratch as a CPU-based filter in C++. It uses the same basic idea as xBR's pattern recognition and interpolation, but with a different rule set designed to preserve fine image details as small as a few pixels. This makes it useful for scaling the details in faces, and in particular eyes. xBRZ is optimized for multi-core CPUs and 64-bit architectures and shows 40–60% better performance than HQx even when running on a single CPU core only.{{Citation needed|date=December 2015}} It supports scaling images with an alpha channel, and scaling by factors from 2x up to 6x. Super xBR[17][18] is an algorithm developed by Hylian in 2015. It uses some combinations of known linear filters along with xBR edge detection rules in a non-linear way. It works in two passes and can only scale an image by two (or multiples of two by reapplying it and also has anti-ringing filter). Super xBR+3D is a version with a 3D mask that only filters 2D elements. There is also a Super xBR version rewritten in C/C++.[19] RotSpriteRotSprite is a scaling and rotation algorithm for sprites developed by Xenowhirl. It produces far fewer artifacts than nearest-neighbor rotation algorithms, and like EPX, it does not introduce new colors into the image (unlike most interpolation systems).[20] The algorithm first scales the image to 8 times its original size with a modified Scale2× algorithm which treats similar (rather than identical) pixels as matches. It then calculates what rotation offset to use by favoring sampled points which are not boundary pixels. Next, the rotated image is created with a nearest-neighbor scaling and rotation algorithm that simultaneously shrinks the big image back to its original size and rotates the image. Finally, overlooked single-pixel details are restored if the corresponding pixel in the source image is different and the destination pixel has three identical neighbors.[21] Kopf–LischinskiThe Kopf–Lischinski algorithm is a novel way to extract resolution-independent vectors from pixel art described in the 2011 paper "Depixelizing Pixel Art".[22][23] Edge-Directed Interpolation (EDI){{tone|section|date=May 2016}}The idea behind edge-directed interpolation (EDI) is to use statistical sampling to ensure the quality of an image when scaling it up.[24] There were several earlier methods that involved detecting edges to generate blending weights for linear interpolation or classifying pixels according to their neighbour conditions and using different otherwise isotropic interpolation schemes based on the classification. Any given interpolation approach boils down to weighted averages of neighbouring pixels. The goal is to find optimal weights. Bilinear interpolation sets all the weights to be equal. Higher order interpolation methods like bicubic or sinc interpolation consider a larger number of neighbours than just the adjacent ones. EDIUpsizerEDIUpsizer[25] is a resampling filter that upsizes an image by a factor of two both horizontally and vertically using NEDI (new edge-directed interpolation).[26] EDIUpsizer also uses a few modifications to basic NEDI in order to prevent a lot of the artifacts that NEDI creates in detailed areas. These include condition number testing and adaptive window size,[27] as well as capping constraints. All modifications and constraints to NEDI are optional (can be turned on and off) and are user configurable. Just note that this filter is rather slow FastEDIUpsizerFastEDIUpsizer is a slimmed down version of EDIUpsizer that is slightly more tuned for speed. It uses a constant 8x8 window size, only performs NEDI on the luma plane, and only uses either bicubic or bilinear interpolation as the fall back interpolation method. eedi3Another edge-directed interpolation filter. Works by minimizing a cost functional involving every pixel in a scan line. It is slow. EEDI2EEDI2 resizes an image by 2x in the vertical direction by copying the existing image to 2*y(n) and interpolating the missing field. It is intended for edge-directed interpolation for deinterlacing (i.e. not really made for resizing a normal image, but can do that as well). EEDI2 can be used with both TDeint and TIVTC, see the discussion link for more info on how to do this.[28] SuperResThe SuperRes[29] shaders use a different scaling method which can be used in combination with NEDI (or any other scaling algorithm). This method is explained in detail here.[30] This method seems to give better results than just using NEDI, and rival those of NNEDI3. These are now also available as an MPDN renderscript. NEDINEDI (New Edge-Directed Interpolation) computes local covariances in the original image, and uses them to adapt the interpolation at high resolution. NNEDINNEDI[31] - nnedi is an intra-field only deinterlacer. It takes in a frame, throws away one field, and then interpolates the missing pixels using only information from the kept field. It has same rate and double rate modes, and works with YUY2 and YV12 input. nnedi can also be used to enlarge images by powers of two. NNEDI2NNEDI2 is an intra-field only deinterlacer. It takes in a frame, throws away one field, and then interpolates the missing pixels using only information from the kept field. It has same rate and double rate modes, and works with YV12, YUY2, and RGB24 input. nnedi2 is also very good for enlarging images by powers of 2, and includes a function 'nnedi2_rpow2' for that purpose. NNEDI3nnedi2 with improved predictor neural network architecture and local neighborhood pre-processing. nnedi3 also has multiple local neighborhood size options to better handle image enlargement vs deinterlacing and give more quality vs speed options. NNEDI3 has a "predictor neural network" that consists of neurons. Possible settings for madvr NNEDI3 neurons are 16, 32, 64, 128, and 256. 16 is fastest. 256 is slowest, but should give the best quality. This is a quality vs speed option; however, differences are usually small between the amount 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. References1. ^{{cite web|url=http://www.datagenetics.com/blog/december32013/index.html|title=Pixel Scalers|publisher=|accessdate=19 February 2016}} 2. ^{{cite web|url=https://amigan.yatho.com/saa5050.pdf |title=Mullard SAA5050 Datasheet}} 3. ^{{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}} 4. ^{{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}} 5. ^{{cite web|last=Thomas |first=Kas |authorlink= | year=1999 |url=http://www.mactech.com/articles/mactech/Vol.15/15.06/FastBlitStrategies/index.html |title=Fast Blit Strategies: A Mac Programmer's Guide |work=MacTech |pages= |publisher= | language= |accessdate= }} 6. ^{{cite web|url=https://github.com/libretro/common-shaders/tree/master/scalenx|title=common-shaders/scalenx at master · libretro/common-shaders · GitHub|author=libretro|work=GitHub|accessdate=19 February 2016}} 7. ^{{ cite web | url = https://libretro.com/forums/archive/index.php?t-1655.html | title = ScaleNx - Artifact Removal and Algorithm Improvement [Archive] | accessdate = 2016-05-27 | deadurl = yes | archiveurl = https://web.archive.org/web/20160527015550/https://libretro.com/forums/archive/index.php?t-1655.html | archivedate = 2016-05-27 | df = }} 8. ^{{cite web|last= |first= |authorlink= | date=2007-01-18 |url=http://everything2.com/index.pl?node_id=1859453 |title=Eagle (idea) |format= |work=Everything2 |pages= |publisher= | language= |accessdate= }} 9. ^{{cite web|url=http://thread.gmane.org/gmane.linux.redhat.fedora.legal/661|title=Gmane Loom|publisher=|accessdate=19 February 2016}} 10. ^{{ cite web | last = Stepin | first = Maxim | url = http://www.hiend3d.com/hq3x.html | title = hq3x Magnification Filter | accessdate = 2007-07-03 | deadurl = yes | archiveurl = https://web.archive.org/web/20070703061942/http://www.hiend3d.com/hq3x.html | archivedate = 2007-07-03 | df = }} 11. ^{{cite web|url=http://filthypants.blogspot.com/2014/06/true-hq2x-shader-comparison-with-xbr.html|title=Filthy Pants: A Computer Blog|author=Hunter K.|publisher=|accessdate=19 February 2016}} 12. ^{{cite web|url=https://github.com/libretro/common-shaders/tree/master/hqx|title=common-shaders/hqx at master · libretro/common-shaders · GitHub|author=libretro|work=GitHub|accessdate=19 February 2016}} 13. ^Byuu. Release announcement Accessed 2011-08-14. 14. ^{{cite web|url=http://libretro.com/forums/showthread.php?t=88|title=xBR algorithm tutorial|publisher=|accessdate=19 February 2016}} 15. ^{{cite web|url=https://github.com/libretro/common-shaders/tree/master/xbr|title=common-shaders/xbr at master · libretro/common-shaders · GitHub|author=libretro|work=GitHub|accessdate=19 February 2016}} 16. ^{{cite web|url=https://sourceforge.net/projects/xbrz/|title=xBRZ|author=zenju|work=SourceForge|accessdate=19 February 2016}} 17. ^{{cite web|url=https://drive.google.com/file/d/0B_yrhrCRtu8GYkxreElSaktxS3M/view?pref=2&pli=1|title=Super-xBR.pdf|work=Google Docs|accessdate=19 February 2016}} 18. ^{{cite web|url=https://github.com/libretro/common-shaders/tree/master/xbr/shaders/super-xbr|title=common-shaders/xbr/shaders/super-xbr at master · libretro/common-shaders · GitHub|author=libretro|work=GitHub|accessdate=19 February 2016}} 19. ^http://pastebin.com/cbH8ZQQT 20. ^{{cite web|url=http://info.sonicretro.org/RotSprite|title=RotSprite|work=Sonic Retro|accessdate=19 February 2016}} 21. ^{{cite web|url=http://forums.sonicretro.org/index.php?showtopic=8848&st=15&p=159754entry159754|title=Sprite Rotation Utility|work=Sonic and Sega Retro Message Board|accessdate=19 February 2016}} 22. ^{{cite journal|author=Johannes Kopf and Dani Lischinski|title=Depixelizing Pixel Art|journal=ACM Transactions on Graphics (Proceedings of SIGGRAPH 2011)|year=2011|volume=30 |issue=4|pages=99:1–99:8|doi=10.1145/2010324.1964994|archiveurl=https://web.archive.org/web/20150901034643/http://research.microsoft.com/en-us/um/people/kopf/pixelart| archivedate=2015-09-01 |url=http://research.microsoft.com/en-us/um/people/kopf/pixelart/|accessdate=24 October 2012}} 23. ^{{cite web|url=http://johanneskopf.de/publications/pixelart/|author=Johannes Kopf|date=2011|publisher=SIGGRAPH|title=Depixeling pixel art|accessdate=2016-05-22}} 24. ^https://www.doom9.org/showthread.php?s=7fb2fb184cfe82b7d76b63bb26df481a&t=170727 25. ^[https://web.archive.org/web/20110811050103/http://web.missouri.edu/~kes25c/ tritical's Avisynth Filters] 26. ^https://web.archive.org/web/20101126091759/http://neuron2.net/library/nedi.pdf 27. ^https://web.archive.org/web/20041221052401/http://www.cs.ucdavis.edu/~bai/ECS231/finaltzeng.pdf 28. ^{{cite web|url=http://forum.doom9.org/showthread.php?p=744308#post744308|title=TDeint and TIVTC - Page 21 - Doom9's Forum|publisher=|accessdate=19 February 2016}} 29. ^{{cite web|url=http://forum.doom9.org/showthread.php?t=170661|title=nnedi3 vs NeuronDoubler - Doom9's Forum|publisher=|accessdate=19 February 2016}} 30. ^{{cite web|url=http://forum.doom9.org/showthread.php?p=1685124#post1685124|title=Shader implementation of the NEDI algorithm - Page 6 - Doom9's Forum|publisher=|accessdate=19 February 2016}} 31. ^{{cite web|url=http://forum.doom9.org/showthread.php?t=129953|title=NNEDI - intra-field deinterlacing filter - Doom9's Forum|publisher=|accessdate=19 February 2016}} 1 : Image processing |
随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识,基本涵盖了大多数领域的百科知识,是一部内容自由、开放的电子版国际百科全书。