Amazing image zoom algorithm, t creates a hires version of a low res image. I would love to see this image zoom feature implemented the in ImageMagick.
There is a technique that might actually be able to do this called compressed sensing[1] that I first heard about it in a Wired article from several years ago[2]. The technique allows reconstructing images, music, etc. by sampling a portion of the original and applying an algorithm that reconstructs the missing information and is apparently used in MRI image processing to get by with shorter scans. Researchers from Rice University constructed a camera with only a single pixel image sensor that, using this technique, produced legible images with as little as a 2% sampling of the final image resolution, although more complex images required 10-20% or more[3]. I don't see why this technique couldn't be used to take already good quality images and "enhance" areas of them like in CSI.
This would be awesome if it was available as a scaler for high-DPI screens and old apps. Or even bundled into televisions for upscaling.
The paper does note that it is designed for hand-edited pixel art, where every different coloured pixel is treated as significant. So I wonder how it behaves when scaling photos?
(Edit: the paper does note that it doesn't do well on anti-aliased graphics...)
Televisions have upscale algorithms. But nothing like this. But they don't need anything like this because they don't scale pixle art with sharp borders and very low resolution. They scale video footage (which one could say is "anti-aliased") with about 640x480 resolution.
I think it depends on what your end goal is. Are you trying to scale and hide the pixel-ness of the original? The "ours" does pretty darn well, especially if you look at the Boo example as mentioned above.
However, if you're looking at in the case of an SNES emulator or something.. then hq4x seems like the best choice. It keeps true to the original pixel art, while appearing significantly better.
Video of Ours vs HQ4X. Ours seems to have a slight advantage to my eyes, admittedly it is a personal preference. Text has a distinct advantage on HQ4X but Mario and Yoshi look better even if less "accurate".
https://research.microsoft.com/en-us/um/people/kopf/pixelart...
I wish they would use this in Windows 8. As far as I can tell, their scaling algorithm for 4k displays is: scale up 2x using nearest neighbor, then randomly drop pixels to get back to 125% or 150%. The result is horrifyingly bad. Not just kind of bad, but unusably bad. (Adding insult to injury, they ClearType the text before scaling.)
I have 4 i7 cores and a $500 graphics card. I feel like it's possible :)
TF2, for example, plays beautifully at 3840x2160@60Hz. Scaling up the graphics for an 800x600 visual novel that plays at 1 frame per 30 seconds is computationally possible.
(The good news is that someone has written an emulator for one VN that I'm working through, so I should be able to play with scaling in that way. If I can get it to compile.)
Do you know if MS is working on Mac-Style resolution independence for W9? I'm currently running a Retina MBP, at 2x res I think, and it works _perfectly_. The first few months some apps didn't work well, but the community adapted very quickly.
Windows has had support for resolution independence where DPI is configurable across a continuum (rather than only available as 1x or 2x scale like on the Mac) for quite some time - the issue is that with a huge legacy application base, a giant morass of drawing technologies, and no shipped "HiDPI" or "Retina" Windows hardware until recently, there's been no real incentive for app developers to support it.
In Windows 7 and 8, WPF apps are already supposed to be resolution independent (vector-based).
Old-style GDI+ apps which aren't marked as "resolution aware" (i.e. almost everything) are poorly scaled by the window manager and hideously ugly.
Right, but as noted in the blog you link the application is still only exposed to 1x or 2x scale (where 1pt = 2px), and then everything is scaled back down.
Prior to retina display Macs, OS X implemented resolution independence as an arbitrary scale factor, with most of the UI elements being vector rendered. You could test it out with Quartz Debug. TextEdit, for example, scaled very nicely and remained crisp at arbitrary scale factors.
They didn't end up using this approach because the 2x mode is so simple, and will likely be the last scale factor really needed (especially with the additional scaling modes).
@DougBTX: Technically, there are 2 scaling levels. There's 1x for normal screens and 2x for retina. If you want one of the intermediate resolutions, it will actually render at 2x, then scale down.
>Windows has had support for resolution independence where DPI is configurable across a continuum (rather than only available as 1x or 2x scale like on the Mac) for quite some time - the issue is that with a huge legacy application base, a giant morass of drawing technologies, and no shipped "HiDPI" or "Retina" Windows hardware until recently, there's been no real incentive for app developers to support it.
The same was true for even longer (IIRC) on the Mac. You could enable it with a hidden preference, but lack of app support, compatibility with existing stuff and lack of hidpi displays at the time made it take the back seat. And vector drawed apps only go that far, you need pixel assets at some point or another.
The 2x scale was just the solution finally used by Apple because of the same kind of issues as you describe for Windows.
It's not just the "legacy application base" or "app developers" which are at fault; even most of Windows itself is still using the old drawing libraries. As soon as you start digging into system properties, MMC, etc, everything is horribly blurry.
But yes, apps are also broken, even very popular ones like Chrome and Steam.
Fair point - even some of the shallowest corners of Windows itself are broken too (like Windows Media Player), although most of the other big user-facing shell apps like Explorer and IE are great.
Google almost had support in Chrome 34 after a few false starts, but it looks to have been disabled yet again in current releases.
Now that Windows users are trying to use Retina MacBooks via BootCamp and 2x-resolution Windows 8 tablets like the IdeaPad Yoga2 are out, the DPI scaling issue is finally starting to get mainstream exposure. Most reviews of the IdeaPad called out Chrome specifically and once 4K displays come down in price the gamer crowd will probably jump on the bandwagon as well.
Old style GDI+ apps that are incorrectly marked as being resolution aware even though they aren't is a bigger problem than programs not marking it at all. If it's not marked you get simple 2x scaling but if it's marked and not implemented properly anything can happen.
What is needed for this to work is a user setting to override the programs own preference. There is just too much legacy cruft that accidentally marked themselves as being resolution aware even if they're not. Or drop the old flag and create a new one called something like "really really resolution aware"
Didn't there used to be a user setting in the "Compatibility" tab?
I haven't played with this stuff in a few years - my housemates and I tried to use a 46" TV in the basement as our web browsing machine for a while and ended up frustrated every time we tried to scale the UI on any platform (OSX, Ubuntu with both Unity and GNOME2, Windows).
It works perfect on the Mac but I wonder if that would be the case if you could still run old 'classic' apps.
You'd think Microsoft of all companies would work in compatibilty fixes for at least the major apps. Like how they worked in so many fixes to make them compatible from 98-XP and such.
"Classic" apps will be scaled (using the normal bicubic filter) to twice their resolution on Mac. If they were implemented using Apple APIs, there's a good chance that text will be at a higher resolution and will appear clear.
Even when there were a few apps that didn't work well, in my experience at least, it was no one near as bad as W8's HiDPI features continue to be today. Apple did a really good job with that.
While something similar would probably be better, this is heavily optimized for pixel artwork. Lots of curves, shading, and most importantly - limited colors. UI is generally much straighter, less shaded, with far more colors.
Here's an example of UI that's scaled with potrace (a similar algorithm): http://i.imgur.com/jDq4M7e.png (left side is the converted side, right side is nearest-neighbor. Top is 3x, bottom is 2x)
That's with the highest amount of colors/depth that potrace allows. On an i7 processor, it takes a LONG time to compute all of that. Each icon is no longer just a couple hundred pixels, it's a couple hundred vector paths. Even rendering it takes a number of seconds to refresh the screen in inkscape.
I think the ideal would be something similar to fonts: there's the vector definition for big sizes, and optional pixel-perfect definition for small sizes, because rendering vectors on very small sizes (16x16, 32x32) might look worse than hand-crafted pixel work.
These days, font rendering does not often rely on bitmaps, even at small sizes. Instead, they typically use hinting and subpixel rendering. I would love to see these effective techniques applied to vector graphics too.
Linux has had vector icons on the desktop for over a decade now. It truly boggles my mind how Apple (especially once they realized Retina was coming) hasn't gone fully resolution-independent on the UI side by now…
I think it comes down to your point of focus. With peach and peach 2, The eyes change shape quite a bit. Humans notice that much more than other aspects.
In general, I think the "ours" method could benefit by moving the boundaries between colours in and out until they get an average brightness match with the similar area in the nearest neighbour version. A lot of the "ours" images have a higher proportion of black.
Super2xSaI looks better to me at 4x than bicubic, and EPX does an OK job but the others look pretty terrible.
I think the problem is that those sprites use multiple strategies for handling diagonal outlines. Those look fine when the image is blurred together, but when you try to detect the outlines and upscale them, the differences between techniques are exaggerated.
Only if you look at the first ones. All of Boo, Dolphin, all of SoM, Invaders, Golden Axe, Windows assets and Lost Vikings look great and have vastly reduced artifacts compared to hqx. Also, according to the paper abstract[0], it outputs vector, not scaled up bitmap.
The Super Mario and Secret of Mana stuff works quite good, except it changes the facial expression on "Peach 2". I'd like to see Donkey Kong Country 1/2/3, Megaman (NES and SNES) and Chrono Trigger processed by this. And not just the sprites cut out of the background but embedded in a scene.
Look at Axe Battler 2 - if the sword isn't vertical, then the result is not superior. Unless, of course, you think the guy is wielding a sawtooth blade.
Not to mention that muscles have a smoothly-graded tone under the 'ours' algorithm, whereas hq4x has an unlifelike blocky effect.
Honestly I think hq4x and "Ours" both look like ass for both of the Axe Battlers. Nearest neighbor is a better choice for either of them. EPX on either is acceptable.
No, hq4x is still better on almost all of them. Microsoft's makes everything too round and blobby. It pretty much only works really well when everything is round, like in Boo. But look at what it does to the Golden Axe characters' faces.
hq4x keeps angles when it should not, degrading many features in the process, and that bothers me much more than the overall change to a bit more blobbiness. Look at the outline of Bowser's horns and mouth, Toad's cap outline, Fake Sage's moustache, or Axe Battler 2 sword. The mouths of invaders are also faithfully reproduced. In the Ports icon, the cable is correctly represented, and the port itself has volume instead of becoming two planes as in hq4x. On the Keyboard one, hq4x produces a good icon, although it rounds the keys a little, while "ours" produces a non-faithful in style but nonetheless correct result. Control Panel is interesting, as "ours" looks like the hq4x version has melted, but the hq4x version produces a result that is semantically similar (piano keys, weird mouse shape, angles in letter) leading me to think the original icon is not exactly the best pixel art material (maybe due to palette constraints).
Maybe the results of "ours" aren't exactly faithful in style in some cases, but they're globally consistent, and I find the shapes semantic more truthful. As for hq4x by itself, I actually prefer the original sprites overall.
I noted the same issue with round vs sharp sections. Honestly, what this needs is a blending function, kind of like how they do intense shocks in fluid dynamics, where it would use MS's algo in areas where it detected significant roundness, and then blend into the hq4x algo in areas where there's more angular sections, like in the treasure box.
I think we're trying to optimize different functions.
For Bowser, I think hq4x is fine (the mouth needs not have a smooth contour like a human's - compare with a dinosaur or a crocodile), but you are giving more weight to the fact that the shaded part on the bottom right of the mouth is broken in several pieces, instead of being a single piece like in ours.
For Fake Sage, I think hq4x does better. A pointy moustache is fine. The "ours" version is practically melted, and hardly recognizable as an old man - it looks more like some sort of fish shaman.
For Axe Battler 2, the shaded part of the sword is jagged in hq4x, but that doesn't bother me. Same thing for the broken black outline in the leg. I am much more bothered by how "ours" messes up his face.
In general, I would say that "ours" is better at putting together some parts that are supposed to be a single line, while hq4x separates them (especially with thin shadows). But graphically, hq4x's result is much more faithful to what the sprite is supposed to represent. With "ours", everything looks like melted ink, or like it's been seen through a wet pane of glass in the rain.
It would be nice to see if it's possible to combine "ours"'s better detection of continuous shades with hq4x's better preservation of straight lines and details.
A big difference in the techniques is that hq4x is a fix-rate upscaling, whereas Microsoft's can handle arbitrary target resolutions. At the same rez, they are pretty equivalent. But, MS has the option to go higher. HQ8x has not yet been developed. I doubt that HQ(arbitrary)x is possible without completely changing the algorithm.
I took great care to compare 4x, only considering 16x as a zoom, especially since "zoomed in", it blows out the details too much so you lose the global picture. Still, 16x means HiDPI will make it looks crisp as hell for the same physical size.
As for the video, the dent in Mario's cap outline and the similar angles in the background outlines ruins hq4x for me, while I could live with the "200"/"400" lettering (which looks better on hq4x) because it disappears quickly (but does not bode well for other cases where text appears)
even so. I suspect a live rendering of the vector process would be fairly attractive. I'd love to see this technique used on the textures for n64 games. The rendering times wouldn't be such an issue in that case.
yeah, it seems to handle patches of complex colouring badly (especially where two tones of the same colour were used to good effect in the icon, but scaled up as messy blobs), but boo and the invaders were very impressive.
The authors of this paper also have other amazing image processing/optimization algorithms. Eg: Deblurring, Optimizing Color Consistency, Content-aware Automatic Photo Enhancement, Object Discovery and Segmentation in Internet Images and more:
> This paper introduces a novel content-adaptive image downscaling method. The key idea is to optimize the shape and locations of the downsampling kernels to better align with local image features. [...] Besides natural images, our algorithm is also effective for creating pixel art images from vector graphics inputs, due to its ability to keep linear features sharp and connected.
IIRC, this is one of the major reasons that vector graphics based icons have not taken off.
Sometimes the Vector Magic results are truly magical; striking poses become even more striking when the figure is reduced to a collection of simpler shapes.
This is a pretty old paper, but I hadn't seen the live demo. That's pretty cool.
A problem with this algorithm is that it's pretty slow. It would be hard to use it for real time scaling.
I think that it's pretty cool though for any precalculated conversion to vector format. It would also be pretty cool if there were software that allowed you to create a pixel art image with a live preview in this format and the ability to export into a vector format.
One of the benefits of pixel art IMO is that it's got a pretty distinct style and its simplicity and restrictions means it's easy to be aware of composition where if you are given an unrestricted canvas that freedom can make it hard to know where to start. If you are given a 8x8 pixel grid to indicate "happy" there's only so many ways to do it, a symbolic heart, a little smiley face, etc. Given a whole sheet of paper you'll have more difficulty.
With the high res displays, there's more to consider than just the upscaling of old programs, the fact is people (especially indie game devs) still want to work with pixel art, and the number of titles with the term "8-bit" in their name that have come out recently. Part of that's because it's in vogue now, but a big part of it is simply that a poor artist can make a passable 24x24 sprite.
But it's still a shame that on high res displays they end up looking like a blocky mess. If you had a program that let you author your sprites under the same conditions, but let you preview an upscaled version and left you with a vector image (or high res texture with mip maps) you can make use of the fidelity while maintaining the simplicity. I think that would be cool.
Well SuperEagle seems even slower for me, and I know for a fact that I can emulate with SuperEagle scaling on and it works fine (>30 FPS). So I don't think their algorithm is out of the question.
> If you had a program that let you author your sprites under the same conditions, but let you preview an upscaled version
Combine Atwood's law with a proposed law of mentioning ideas on HN being implemented shortly thereafter and there may be a HTML5+JS implementation popping up as a "Show HN" soon.
Am I crazy for preferring the one on the left (nearest-neighbour)? The other two really mess up certain details such as the point numbers, the stem of the fruits and pokey's eyes.
They also tend to cause a very subtle distortion of the outlines of foreground sprites as they move over the background.
No, you aren't. I prefer nearest-neighbor too, I think it preserves the "spirit" of the game. Generally speaking, I prefer it for any kind of "pixel art".
That said, those algorithms are impressive, and I can see why someone could prefer them over a simple nn.
This reminds me of staring at those tiny screenshots on the back of NES boxes with sweaty palms as a six year old.. lol.. Pixel art was not yet embraced as an art form, I guess. (well, not by the adults)
As interesting as these smoothing algorithms are, they can't add any information to the sprites that wasn't already there. Why make everything look smooth and plasticky when the original game was carefully hand-drawn, pixel by pixel?
I think there is a purpose for this in video, but I'm not sure it's an all or nothing game. Especially here. For starters, the gameplay looks smoother in nearest neighbor because your eyes defocus while playing. Hence, you need sharp pixel edges to dilettante and your eyes do the rest. In a still shot, that's not the case at all. You want focus and smoothness.
I preferred hq4x for much the same reason. Removed the large blockiness while still preserving the pixelated feel (and staying truer to the shapes in the original).
Is the video based on applying the algorithm to the entire screen, or is it applied to the sprites individually, then they are plotted to the screen?
Just wondering, because the samples in the paper are all lone objects against a clear background. If the same object is drawn in front of a detailed background and then the upscaling is applied, this would affect the patterning. It's a little tricky to tell from the video, since the graphics (especially the backgrounds) use large blocks of plain colours.
Worst case, you could imagine Mario walking in front of the background and his shape shifting madly with every step he took?
(Edit: From freeze-framing the video, I'm guessing that the algorithm is being applied to the whole screen. The scaling works great when Mario is in front of the pale background. There are small artifacts when he crosses the black outline of the green bushes. Very minor in this video, I wonder how it would affect more intricate backgrounds or those that aren't such contrasting colours to the foreground?)
> Worst case, you could imagine Mario walking in front of the background and his shape shifting madly with every step he took?
This brings up something interesting: In terms of media containing sprites and minimal layering (e.g. NES-like games), wouldn't it be computationally cheaper to perform the scaling on the sprites and textures independently of one another, instead of post-processing? I wonder if there is any emulator that does this. I'm thinking not, as the NES wouldn't be capable of layering such detail (large sprites + textures). Upsampling emulators.. Hmm...
It'd be kind of hard, as what makes up a "sprite" lives in two different places - one that stores all the tile data, and another that basically describes which tiles make up which sprites. The latter is likely to change every frame, and potentially the former, too, so you'd still be rescaling some stuff every frame. You'd also have to rescale some things that are affected by palette changes, which sometimes change every frame (popular way to animate water, for example). Would you end up saving time this way? I'm not really sure. It's definitely an interesting idea.
i dont understand, as long as you figure out how to get the sprites into the right formats this would be immensely computationally cheaper ("time-saving"?) than post-processing every frame
The thing is, there's no "right format" for sprites, as they're used in the game. See http://benfry.com/deconstructulator/ for an example of how sprites are handled by the NES for Super Mario Bros. Mario is split into 8x8 pieces that are swapped out as needed: how do you determine which pieces are "Mario's sprite" and which are "that coin's sprite"? Remember that some pieces will change while others won't.
yea i dont doubt it would be complex & to build an upsampling sprite rendering engine you'd have to understand all this stuff. With old games like this it would probably involve some manual work cuz you'd have to recompose images, smooth as a unit, then decompose somehow back to the original tiling. I mean.... I'm not gonna do it & wouldn't bother trying
the computational price will be much much cheaper tho. swap in upsampled sprite (36 tiles to every 1 in old format, let's say) rather than post-processing every single frame in real-time with a smoothing/upsampling algorithm.
it would also keep the pieces distinct from each other rather than having objects/characters/backgrounds morph in & out of one another
Count me as another one who likes the pixel aesthetic. The title made me ask myself "why would you want to do this?"
(I also loathe most forms of antialiasing, including ClearType, so that might have something to do with it... I like sharp, clearly contrasted edges, including pixel edges.)
163 comments
[ 4.1 ms ] story [ 189 ms ] thread[1] https://en.wikipedia.org/wiki/Compressed_sensing [2] http://www.wired.com/magazine/2010/02/ff_algorithm/ [3] http://dsp.rice.edu/cscamera
https://news.ycombinator.com/item?id=2673271
and links to +1000 day old threads:
https://news.ycombinator.com/item?id=2601347
https://news.ycombinator.com/item?id=2578706
yet those space invaders still haunt me.
The paper does note that it is designed for hand-edited pixel art, where every different coloured pixel is treated as significant. So I wonder how it behaves when scaling photos?
(Edit: the paper does note that it doesn't do well on anti-aliased graphics...)
However, if you're looking at in the case of an SNES emulator or something.. then hq4x seems like the best choice. It keeps true to the original pixel art, while appearing significantly better.
Video of Ours vs HQ4X. Ours seems to have a slight advantage to my eyes, admittedly it is a personal preference. Text has a distinct advantage on HQ4X but Mario and Yoshi look better even if less "accurate". https://research.microsoft.com/en-us/um/people/kopf/pixelart...
TF2, for example, plays beautifully at 3840x2160@60Hz. Scaling up the graphics for an 800x600 visual novel that plays at 1 frame per 30 seconds is computationally possible.
(The good news is that someone has written an emulator for one VN that I'm working through, so I should be able to play with scaling in that way. If I can get it to compile.)
In Windows 7 and 8, WPF apps are already supposed to be resolution independent (vector-based).
Old-style GDI+ apps which aren't marked as "resolution aware" (i.e. almost everything) are poorly scaled by the window manager and hideously ugly.
It isn't continuous, but there are more than two scaling levels on OS X:
https://blog.qt.digia.com/wp-content/uploads/2013/04/qtRetin...
More details: https://blog.qt.digia.com/blog/2013/04/25/retina-display-sup...
On Windows the app is exposed to the scale factor (for better or worse): https://blog.qt.digia.com/blog/2009/06/26/improving-support-...
They didn't end up using this approach because the 2x mode is so simple, and will likely be the last scale factor really needed (especially with the additional scaling modes).
The same was true for even longer (IIRC) on the Mac. You could enable it with a hidden preference, but lack of app support, compatibility with existing stuff and lack of hidpi displays at the time made it take the back seat. And vector drawed apps only go that far, you need pixel assets at some point or another.
The 2x scale was just the solution finally used by Apple because of the same kind of issues as you describe for Windows.
But yes, apps are also broken, even very popular ones like Chrome and Steam.
Google almost had support in Chrome 34 after a few false starts, but it looks to have been disabled yet again in current releases.
Now that Windows users are trying to use Retina MacBooks via BootCamp and 2x-resolution Windows 8 tablets like the IdeaPad Yoga2 are out, the DPI scaling issue is finally starting to get mainstream exposure. Most reviews of the IdeaPad called out Chrome specifically and once 4K displays come down in price the gamer crowd will probably jump on the bandwagon as well.
What is needed for this to work is a user setting to override the programs own preference. There is just too much legacy cruft that accidentally marked themselves as being resolution aware even if they're not. Or drop the old flag and create a new one called something like "really really resolution aware"
I haven't played with this stuff in a few years - my housemates and I tried to use a 46" TV in the basement as our web browsing machine for a while and ended up frustrated every time we tried to scale the UI on any platform (OSX, Ubuntu with both Unity and GNOME2, Windows).
You'd think Microsoft of all companies would work in compatibilty fixes for at least the major apps. Like how they worked in so many fixes to make them compatible from 98-XP and such.
Here's an example of UI that's scaled with potrace (a similar algorithm): http://i.imgur.com/jDq4M7e.png (left side is the converted side, right side is nearest-neighbor. Top is 3x, bottom is 2x)
That's with the highest amount of colors/depth that potrace allows. On an i7 processor, it takes a LONG time to compute all of that. Each icon is no longer just a couple hundred pixels, it's a couple hundred vector paths. Even rendering it takes a number of seconds to refresh the screen in inkscape.
OTOH, for icons, you just need to compute that once and then cache the png.
2. We just need vector-based icons already.
See? Even he doesn't know what to call it!
In general, I think the "ours" method could benefit by moving the boundaries between colours in and out until they get an average brightness match with the similar area in the nearest neighbour version. A lot of the "ours" images have a higher proportion of black.
I think the problem is that those sprites use multiple strategies for handling diagonal outlines. Those look fine when the image is blurred together, but when you try to detect the outlines and upscale them, the differences between techniques are exaggerated.
backup on archive.org: https://web.archive.org/web/20120630044334/http://www.hiend3...
http://en.wikipedia.org/wiki/Hqx
Source: https://code.google.com/p/hqx/source/browse/trunk/src/hq4x.c
[0]: http://research.microsoft.com/en-us/um/people/kopf/pixelart/
Not to mention that muscles have a smoothly-graded tone under the 'ours' algorithm, whereas hq4x has an unlifelike blocky effect.
Maybe the results of "ours" aren't exactly faithful in style in some cases, but they're globally consistent, and I find the shapes semantic more truthful. As for hq4x by itself, I actually prefer the original sprites overall.
For Bowser, I think hq4x is fine (the mouth needs not have a smooth contour like a human's - compare with a dinosaur or a crocodile), but you are giving more weight to the fact that the shaded part on the bottom right of the mouth is broken in several pieces, instead of being a single piece like in ours.
For Fake Sage, I think hq4x does better. A pointy moustache is fine. The "ours" version is practically melted, and hardly recognizable as an old man - it looks more like some sort of fish shaman.
For Axe Battler 2, the shaded part of the sword is jagged in hq4x, but that doesn't bother me. Same thing for the broken black outline in the leg. I am much more bothered by how "ours" messes up his face.
In general, I would say that "ours" is better at putting together some parts that are supposed to be a single line, while hq4x separates them (especially with thin shadows). But graphically, hq4x's result is much more faithful to what the sprite is supposed to represent. With "ours", everything looks like melted ink, or like it's been seen through a wet pane of glass in the rain.
It would be nice to see if it's possible to combine "ours"'s better detection of continuous shades with hq4x's better preservation of straight lines and details.
There was a video posted here, with them rendered at the same resolution side by side.
https://news.ycombinator.com/item?id=7307975
It's really a matter of taste in this video.
A big difference in the techniques is that hq4x is a fix-rate upscaling, whereas Microsoft's can handle arbitrary target resolutions. At the same rez, they are pretty equivalent. But, MS has the option to go higher. HQ8x has not yet been developed. I doubt that HQ(arbitrary)x is possible without completely changing the algorithm.
As for the video, the dent in Mario's cap outline and the similar angles in the background outlines ruins hq4x for me, while I could live with the "200"/"400" lettering (which looks better on hq4x) because it disappears quickly (but does not bode well for other cases where text appears)
https://news.ycombinator.com/item?id=2601347
https://news.ycombinator.com/item?id=2578706
Dani Lischinski's page: http://www.cs.huji.ac.il/~danix/
Johannes Kopf page: http://johanneskopf.de/
http://research.microsoft.com/en-us/um/people/kopf/downscali...
> This paper introduces a novel content-adaptive image downscaling method. The key idea is to optimize the shape and locations of the downsampling kernels to better align with local image features. [...] Besides natural images, our algorithm is also effective for creating pixel art images from vector graphics inputs, due to its ability to keep linear features sharp and connected.
IIRC, this is one of the major reasons that vector graphics based icons have not taken off.
A problem with this algorithm is that it's pretty slow. It would be hard to use it for real time scaling.
I think that it's pretty cool though for any precalculated conversion to vector format. It would also be pretty cool if there were software that allowed you to create a pixel art image with a live preview in this format and the ability to export into a vector format.
One of the benefits of pixel art IMO is that it's got a pretty distinct style and its simplicity and restrictions means it's easy to be aware of composition where if you are given an unrestricted canvas that freedom can make it hard to know where to start. If you are given a 8x8 pixel grid to indicate "happy" there's only so many ways to do it, a symbolic heart, a little smiley face, etc. Given a whole sheet of paper you'll have more difficulty.
With the high res displays, there's more to consider than just the upscaling of old programs, the fact is people (especially indie game devs) still want to work with pixel art, and the number of titles with the term "8-bit" in their name that have come out recently. Part of that's because it's in vogue now, but a big part of it is simply that a poor artist can make a passable 24x24 sprite.
But it's still a shame that on high res displays they end up looking like a blocky mess. If you had a program that let you author your sprites under the same conditions, but let you preview an upscaled version and left you with a vector image (or high res texture with mip maps) you can make use of the fidelity while maintaining the simplicity. I think that would be cool.
Combine Atwood's law with a proposed law of mentioning ideas on HN being implemented shortly thereafter and there may be a HTML5+JS implementation popping up as a "Show HN" soon.
Even if it's too slow for realtime on today's hardware, I'd love to see some prerendered sample videos.
They also tend to cause a very subtle distortion of the outlines of foreground sprites as they move over the background.
That said, those algorithms are impressive, and I can see why someone could prefer them over a simple nn.
The art-direction of games from this era wasn't done with the intention that these games would be played on pixel-perfect computer monitors, though. The art was designed and tested for CRT TVs, which would generally give you something like http://i385.photobucket.com/albums/oo299/muddi900/LTTP3xNTSC..., or even http://4.bp.blogspot.com/_Kzdww8T9fUA/TRplyGIj6PI/AAAAAAAAAt...
edit: proof: https://www.google.com/search?q=nes+box+back&tbm=isch
Interesting though...
I'm surprised none of these algorithms are made to keep state between frames, so they can keep things like this consistent.
Just wondering, because the samples in the paper are all lone objects against a clear background. If the same object is drawn in front of a detailed background and then the upscaling is applied, this would affect the patterning. It's a little tricky to tell from the video, since the graphics (especially the backgrounds) use large blocks of plain colours.
Worst case, you could imagine Mario walking in front of the background and his shape shifting madly with every step he took?
(Edit: From freeze-framing the video, I'm guessing that the algorithm is being applied to the whole screen. The scaling works great when Mario is in front of the pale background. There are small artifacts when he crosses the black outline of the green bushes. Very minor in this video, I wonder how it would affect more intricate backgrounds or those that aren't such contrasting colours to the foreground?)
This brings up something interesting: In terms of media containing sprites and minimal layering (e.g. NES-like games), wouldn't it be computationally cheaper to perform the scaling on the sprites and textures independently of one another, instead of post-processing? I wonder if there is any emulator that does this. I'm thinking not, as the NES wouldn't be capable of layering such detail (large sprites + textures). Upsampling emulators.. Hmm...
the computational price will be much much cheaper tho. swap in upsampled sprite (36 tiles to every 1 in old format, let's say) rather than post-processing every single frame in real-time with a smoothing/upsampling algorithm.
it would also keep the pieces distinct from each other rather than having objects/characters/backgrounds morph in & out of one another
(I also loathe most forms of antialiasing, including ClearType, so that might have something to do with it... I like sharp, clearly contrasted edges, including pixel edges.)