Live data from Hacker News

Depixelizing Pixel Art

research.microsoft.com

161–164 of 164 posts

Re: Depixelizing Pixel Art

#161
post #43

Earlier quoted context omitted.

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 2…

1. That looks awful. 2. We just need vector-based icons already.

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…

Re: Depixelizing Pixel Art

#162
post #152

Earlier quoted context omitted.

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 ev…

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.

Re: Depixelizing Pixel Art

#163
post #162
post #152

Earlier quoted context omitted.

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

Re: Depixelizing Pixel Art

#164

Earlier quoted context omitted.

I've been thinking about doing something like this. Compress images down to half resolution, then train a neural network to blow it back up and guess the pixels as accurately as possible.

I did something very much like this years ago (upscaling used to be an obsession of mine). The results were pretty disappointing. But there's a lot of space to explore there in terms of choosing and designing the neural net, choosing the right training set, and figuring out an initial transform for data that is input to the neural net.

New deep learning techniques might help this approach a lot.
Post reply on HN