Vector vengeance: Researchers claim they can kill the pixel within five years

Sigh. TL;DR version - scaling pixels makes them blocky, scaling vectors doesn't, for some small range of scaling we can keep upscaled pixels not blocky.<p>Upscaling has a lot of research behind it. Creating a 'vectorized' version of an image (see their paper here: <a href="http://eprints.gla.ac.uk/47879/1/ID47879.pdf" rel="nofollow">http://eprints.gla.ac.uk/47879/1/ID47879.pdf</a>) certainly helps avoid dumb scaling issues. But when you blow it up 7x (like the example) it looks like a cartoon or a bad paint by numbers painting. The issue is that you lose information about the picture when you capture it, and without that information you have to 'make up' what you think would have been there had you been able to capture it. People get a lot of mileage out of the fact that for the most part real world imagery has a lot of linear transitions but there are limits to that as well.<p>I think the work is interesting but as they say in their paper: <i>"What we have shown already is that there is a viable continuous image format and that it can be used for some conventional operations which are not handled easily in sampled formats."</i> which I agree with, but the pixel is not yet in danger of extinction :-)

Slightly side question:<p>If JPG and video codecs already store information in terms of wavelets, frequencies, or whatever have you --<p>Are there any programs that will render JPG or videos at a higher-than-native resolution?<p>I know you're not gaining any extra signal. But if you have a 320x240 video, and you want to play it full-screen at 1280x960 -- instead of rendering at 320x240 and then naively upscaling 4x, would some kind of direct codec rendering to 1280x960 possibly produce more accurate results?<p>If the codec/format is doing a good job at extracting "meaning" from the original image for its compression, it seems like it ought to.

Quick reminder for everyone: A Pixel is Not a Little Square! <a href="http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf" rel="nofollow">http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf</a><p>It's a Sample. There are many ways to filter a collection of samples to reconstruct an image. Drawing bigger squares with nearest-neighbor sampling is only one of them. Depending on the context of your application, you might even go as far as the linked article: <a href="http://www.extremetech.com/gaming/84040-depixelizing-pixel-art-upscaling-retro-8bit-games" rel="nofollow">http://www.extremetech.com/gaming/84040-depixelizing-pixel-a...</a>

You're never going to kill the pixel until you have a display that doesn't use them.

The method they use for vectorization is cool (vectorizing Y, U and V independently) and also illustrates why subsampling UV yields such good results (for standard raster-based codecs).<p>Ultimately however vectors are far more expensive to rasterize than bitmaps, especially if you want antialiasing along edges. There was a bunch of noise a while back about NVIDIA's path rendering extension -- they do antialiasing via 16x multisampling (!!!) NOT a mobile friendly approach.

I'm struggling to understand what the point is. Video codecs don't store data in "pixel" format either, they store wavelet coefficients, data from the frequency domain.<p>From the article, the source data is in pixel format. No codec format can be better than the source data. And the output is displayed on a screen with pixels. Pixels in, pixels out. The intermediate format can only make things worse, not better. It's not surprising that they're able to do better than current formats: it sounds like they're using a huge amount of CPU for encoding. You could get better compression if you created a new MPEG4 profile that required more CPU too.<p>The intermediate format may be tweaked to provide better results while scaling, but you could probably add scaling hints to more conventional codecs, too. Not sure what the point would be either unless the source data had a lot more pixels than the output format...

The most important line in the article is this one towards the end:<p><pre><code> Ultimately, though, I think it will take a lot more than a new codec to kill the pixel.</code></pre>

Summary: Video Codec based on vectorization of images rather than pixel encoding. Slow, but highly parallel. Not much info. Developers hope to have a codec for commercial use in some number of years.<p>PDF of authors' previous work on still images: <a href="http://eprints.gla.ac.uk/47879/1/ID47879.pdf" rel="nofollow">http://eprints.gla.ac.uk/47879/1/ID47879.pdf</a><p>Still too long?: "Mona Lisa in 50 Polygons[1]" Grows Up.<p>␄<p>[1] <a href="http://rogeralsing.com/2008/12/07/genetic-programming-evolution-of-mona-lisa/" rel="nofollow">http://rogeralsing.com/2008/12/07/genetic-programming-evolut...</a>

Vector art is not often the holy grail as it seems. Take fonts, for instance. Even though formats like TrueType stores the data in vector format, numerous resolution-dependent "hints" have to be added to make it more readable.<p>Similarly vector icons appear more blurry than pixelled ones especially at lower resolutions. Extremely scaled images are unimpressive due to loss of detail.<p>Vector art often works well in a certain range of resolutions. The "infinite scaling" promise should be taken with a grain of salt.

Aren't HiDPI displays killing pixels?

Man, Lena really is everywhere.