21–30 of 32 posts
Earlier quoted context omitted.
The 'D' in 'HiDPI' stands for 'dots', a pixel is one dot.
Well, obviously. I meant in the sense of making worrying about pixels irrelevant. To paraphrase the old koan - if a pixel is too small to be seen, does it really exist?
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. Similarly vector icons appear more blurry than pixelled ones especially at lower resolutions. Extremely scaled images are unimpressive due to loss of detail. Vector art often works well in a ce…
While true, font hinting is thankfully finally going the way of the dodo. Cell phones and other handheld devices has very crisp fonts without any aliasing and hinting thanks to their high pixel density. The magic threshold is at about 150 dpi which when passed makes hinting redundant. Desktop displays are getting there, albeit slowly. To slowly for my taste. OS X already doesn't use hinting which is why if you are used to Windows fonts, os x fonts can look blurry. But with then new retina displays os x's text rendering simply looks amazing.
Slightly side question: If JPG and video codecs already store information in terms of wavelets, frequencies, or whatever have you -- Are there any programs that will render JPG or videos at a higher-than-native resolution? 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…
For audio, there's spectral band replication which works well in a large part because harmonics make audio rather correlated across multiple frequencies. Images have much less correlation, and thus processing in the frequency domain is less useful.
Additionally, especially with codecs with a small DCT like JPEG, it's been shown that once you reach a certain quantizer (throwing away all higher frequencies, effectively downscaling in the frequency domain), it becomes better to do a traditional downscale + upscale around the lossy coding.
Or, to put it another way, you can exploit the properties of a how a specific lossy codec discards information to get closer to the original image (deblocking filters are the most common example). There is a significant amount of research on this topic for JPEG. But if you could exploit the properties of the DCT or wavelets for better upscaling, it would work equally well as a codec-agnostic algorithm. Frequency transforms are perfectly reversible assuming infinite precision math, after all.
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). 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…
Do you have any links? I've seen the NVIDIA talk about the extension, but I didn't hear any of the noise about issues with it.
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. PDF of authors' previous work on still images: http://eprints.gla.ac.uk/47879/1/ID47879.pdf Still too long?: "Mona Lisa in 50 Polygons[1]" Grows Up. ␄ [1] http://rogeralsing.com/2008/12/07/genetic-programming-evolut...
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. PDF of authors' previous work on still images: http://eprints.gla.ac.uk/47879/1/ID47879.pdf Still too long?: "Mona Lisa in 50 Polygons[1]" Grows Up. ␄ [1] http://rogeralsing.com/2008/12/07/genetic-programming-evolut...
Aren't most video algorithms "highly parallel"?
The more data (from earlier in the bitstream/image) you can use for prediction, the higher a compression ratio you can achieve. But the more data you use, the more sequential you become, since you have to wait for it to become available before proceeding.
Modern codecs generally don't require a single frame to be parallelizable for encode or decode, and you must sacrifice either latency (encode/decode multiple frames at once) or compression (split a single frame up into parallelizable slices) to become more than slightly parallel.
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. Similarly vector icons appear more blurry than pixelled ones especially at lower resolutions. Extremely scaled images are unimpressive due to loss of detail. Vector art often works well in a ce…
> 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. While true, font hinting is thankfully finally going the way of the dodo. Cell phones and other handheld devices has very crisp fonts without any aliasing and hinting thanks to their high pix…
Is it really so low? That's 20 dots per 10 points; surely you'd notice if a glyph was supposed to be symmetric, but it actually had 10 pixels on one side and 9 on the other. Also, Metafont does hinting, and Knuth must have intended to print taocp at a higher resolution than that.
Slightly side question: If JPG and video codecs already store information in terms of wavelets, frequencies, or whatever have you -- Are there any programs that will render JPG or videos at a higher-than-native resolution? 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…