Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Sub-pixel re-workings of YouTube and BBC favicons (typophile.com)
154 points by marcusbooster on Sept 15, 2009 | hide | past | favorite | 44 comments


Another blog post by the same author introduces a 3 pixel font taking advantage of the subpixels: http://typophile.com/node/61920

I might get that for xemacs and annoy coworkers with 500-character long lines. "But they don't wrap on my screen!"


That is amazing, make sure to scroll down to the zoomed in "ipsum dolor."


Damn…


Heh, I have made 2-pixel-wide text before. I certainly wasn't as pretty as the 3-pixel one here... but it worked! It always impresses people, but there are so many "gotchas" that it's really not practical.


I did a 1-pixel-wide font some year ago. It's not that hard, for instance look at the 'i':

    *

    *
    *
    *
Other chars are similar to this.


Link?


I made a 'sub-pixel accuracy scrolling' demo once on the Gameboy Color: one half of the screen scrolling at 1 pixel a frame, the other at 1/3 pixels. Amazing how jarring the normal scrolling looks once you get used to the sub-pixel smoothness.


This is kinda neat demo of subpixel rendering:

http://antigrain.com/research/font_rasterization/sample_aria...

Each line shifts 0.1px to right. Taken from.

http://antigrain.com/research/font_rasterization/index.html

which is excellent introduction to subpixel rendering


Got a link to a ROM? I’d like to see that.


Interesting idea.

Unfortunately, I have one of my LCDs rotated 90 degrees and, so, any sub-pixel smoothing fails miserably unless it accounts for the rotated sub-pixels.


Perhaps there needs to be a new standard for pngs where you can have one image for each subpixel order.

Or we can get everyone to use RGB. Either would work.


This problem would also be solved by actual widespread support for SVG or something similar. With vector rendering, we can just let the client handle any subpixel business.


When you're trying to communicate a handful of pixels of information why send the entire (complex) vector file?


For the exact reason I stated: portability. Bitmaps are good for some things, but logos aren't really one of them.


But in this case we're talking about a logo that's going to appear a few pixels wide on all clients - there's really no incentive to add the overhead of a large file transmission (not to mention the requisite client-side processing).

In a everything-is-made-of-marshmallows ideal world, yeah, bandwidth is not an issue, nor is site load time, and client-side CPUs and RAM are infinite. In that world I too would transmit everything, no matter how minor, in vector form. We do not live in that world.


The YouTube favicon.ico is 318 bytes long. I threw together a crappy SVG mockup of the logo with absolutely no size optimization, and it clocks in at 429 bytes. When gzipped, they clock in at 233 and 248 bytes, respectively.

If you're worried more about the 15 bytes than about compatibility, then just have the logo scale up and use it for your main logo as well; it should actually save bandwidth that way.


Something that people often forget when dissing vectors and SVG in particular, is that they're _scalable_ - so you can use the same version everywhere. So, you send the logo SVG once, and you could use it for the main logo on the homepage, smaller footer logo on the rest of the site AND for the favicon, because it'll scale. Browser just downloads one SVG file once, instead of 3 different bitmaps. Obviously, this is in everything-is-made-of-marshmallows ideal world where Internet Explorer doesn't exist, but hey.


Technically SVG is scalable, but not in practice. Small icons need different design than large icons, and SVG doesn't solve that. Look at fonts, they have hinting system to indicate changes for different sizes. Without similar system, SVG can't produce icons that truly are scalable. It's especially important in small icons like favicon(16x16px) which I believe will be hand drawn for long time.

I think that Apple does resolution independent icons by embedding several bitmap versions with a vector version in their icon files. That's the way to go in desktop applications, but similar system would produce too much overhead without significant advantage in web.


True, although the hinting is mostly just used for when things get tiny. SVG works well from sizes from 32x32 up to infinity, which is fairly impressive, I think.


Why should anyone be telling me what format decisions I make in the end? If SVG is right for the job, I'll use SVG. If it isn't, I won't. We do have a choice, here.


Why not just reference a larger .png file in your HTML and let the browser deal with the specifics?


Independent of subpixel rendering issues, a good iconographer will tweak an icon at different sizes, even if they originally created it from a vector. Pixels do matter.


The bigger download would slow things down.

Not sure if image resizing could even make sensible use of sub-pixel rendering...


A 32x32 PNG would not be that much larger than a 16x16.


Another solution is to put the pixel order in the html header.

A smart browser showing the same page spread over two different monitors would then download twice as much, but everyone else would be happy.


No. HTML has no reason to specify information that has meaning to display technologies we happen to use now. Subpixel anti-aliasing is based on current LCD technology and doesn't even deal with newer approaches such as the PixelQi screen that equips the OLPC laptop (9 subpixels per pixel).

This solution would pollute the HTML information space.


Very interesting. Apparently we can make images clearer by shifting the red half a pixel to the left and the blue half a pixel to the right (very roughly speaking; I know there is more to it than that).

What's up with that? Can anyone find/give an explanation of this phenomenon?

EDIT: This guy Miha is amazing. Check out this tiny little font he is working on (go to nearly the bottom of the page for a more complete version):

http://typophile.com/node/61920


It's from a phenomenon known as chromatic aberration which is a characteristic of lenses, including the one in your eye (more so if you have astigmatism).

Have you ever looked at someone silhouetted by a bright light, and noticed color fringing on the left and right sides? That's the reason (if you haven't, you have very good eyes). It's also something you often see on photos from cheap digital cameras, where it is introduced by cheap lenses shining onto tiny sensors: http://en.wikipedia.org/wiki/Chromatic_aberration

Interestingly, if you look at the typophile page through a vertically-oriented prism, you'll see similar color fringing on both images - the giant red and white 'pixels' in authentic favicon will shift towards...yellow and purple. Make sure you are looking through the second rotation of the prism - the first rotation does not induce color fringing but reverses left and right instead.

edit: Also, someone should hire that guy, like now.


No, I'm sorry, but none of what you wrote is correct.

The color fringing is due to an effect similar to a diffraction grating. It's caused by light bending as it travels near an edge (like a prism makes a rainbow by bending light). Chromatic aberration exists, but has nothing to do with the color fringing.

The color fringes on the icon are clearer because an LCD monitor actually has 3 times as many pixels as the typical count. It has 3 pixels for each normal pixel: one for Red, Green, and Blue.

These images make use of that, to basically have 3 times the resolution of an ordinary image. So smaller details are now visible.

It doesn't work on CRT's (it actually looks worse). And it only works on LCD's if the order of the sub-pixels is the same as what the author expects.


Don't be sorry, I was wrong. Diffractive lenses are used in camera lenses to correct chromatic aberration from refractive lenses, so I sloppily equated the two. Thanks for your clear explanation!

It is true about the prismatic color-shifting, though - I have one on the desk so that was an observation rather than a hypothesis.


That's amazing. Stuff at this scale is so difficult to work with, one pixel is the difference between readable and unreadable.


What about a paint-style program where the user is presented in one side with the magnified version of the image that is actually split into RBG, and the actual image on the other side? This could allow to do similar things much more easily.


Wouldn't it be rendered differently depending on displays, OS, etc.? I'm wondering if it's just an exercise or if it could be really used.

It's interesting and I wish s/he went into more details on how to do it.


It's called Sub-pixel rendering.

http://en.wikipedia.org/wiki/Sub-pixel_rendering

And google it also, there are many sites that explain it, so I won't repeat them.

It only works on LCD's, and the order of the sub-pixels on your LCD has to match the authors.

There is an option you can set to tell your OS to use sub-pixels when anti-aliasing fonts.

Basically for each pixel, there are actually 3, one for each of red, green, blue. By using this, you can increase the horizontal resolution by a factor of three (more or less).

Horizontal resolution, because most LCD's have the three sub-pixels in a horizontal row.


"Only works on LCDs", I'd question. I've seen it working on CRT screens too, and I see no reason it wouldn't - they also have 3 subpixels horizontally.


From wikipedia:

"The technology is well-suited to LCDs and other technologies where each logical pixel corresponds directly to three independent colored sub-pixels, but less so for CRTs. In a CRT the light from the pixel components often spread across pixels, and the outputs of adjacent pixels are not perfectly independent. If a designer knew precisely a great deal about the display's electron beams and aperture grille, subpixel rendering might have some advantage. But the properties of the CRT components, coupled with the alignment variations that are part of the production process, make subpixel rendering less effective for these displays."

Depends on your screen, but mine has the colors in a triangle. This means that the same colors are not always on the same side of the pixel, so you can't use sub-pixel rendering (see the picture in the article, basically the green is first on the left, then on the right, and back and forth). If you have a Trinitron monitor it could work though.


Sub-pixel is a new way of captcha generating.


I actually hate the one on the right. I don't want my favicons to be necessarily readable, or a blur of colors like that.. they're ICONS. Visual REPRESENTATIONS. Infact, most of the 'better' versions on that page sucked a lot more to my eyes.


Visual REPRESENTATIONS can still be improved using subpixel antialiasing, even if there's no text on them.


How good are your eyes? - I am curious about whether you have had them tested and if so what visual acuity score you received. It might very well be your vision is abnormally sharp and the colors are a distraction.


My eyes are very good. Infact, even sitting at a distance of a few meet I can see individual pixels and sometimes even the subpixels.


Me, too.

The ones on the right appear as a blur of color.

Anti-aliased fonts always, similarly, look color-smudged to me, so I make sure to turn off that "feature" completely, whenever I can.

I suspect that, unlike some replies have implied, this isn't a defect in visual acuity (which could be the case, since the one eye I didn't bother to have laser surgery on is far from normally shaped), but, rather, an increase in sensor resolution. Might we have more cones? Perhaps our cones are distributed differently? Do we saccade [if you'll pardon the verbing] at a different frequency and/or to a different extent?

If my dominant eye can focus the image (unassisted now, with spectacles pre-surgery), I tend to prefer smaller font sizes, even on a tight pitch like a 17" 1920x1200. I still wish Apple would come out with a 15" laptop with 1200 vertical pixels.


Are you using an LCD monitor?


Yes, I am.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: