About those vector icons | Hacker News Reader

About those vector icons

pushing-pixels.org

284 pointsaaronpk40 comments

Oxygen icons (by KDE project) use SVG for all sizes of icons. Here is an example:

http://wstaw.org/m/2012/03/18/plasma-desktopA20554.png

(The icon on the left is suited for 16x16 size. The icon in right is the same icon, just suited for larger scales)

I think this scheme is supported by FreeDesktop.org's Icon Theme Specifications and other icon theme's used on Linux desktops (like Tango) use the same scheme.

Indeed, in that they have multiple SVG versions of the same icon (name) for smaller pixel sizes - 16x16, 22x22, 24x24, 32x32 - the last time I checked.

That seems like the appropriate compromise, SVG for various optical sizes. The analog example that comes to mind is Dr. Seuss books. The Cat in the Hat is much less detailed when he is far away, and has very detailed pen work close up.

Long but good article.

Glad he got into (and linked to the excellent article about) font hinting, because that is of course the solution. A simple vector format is not enough, you need to define what parts should scale how, which are rigid, which are elastic.

I don't think higher resolution displays actually help, because the real limitation becomes the human eye. Though the new display could use the 'old' normal sized icons as small ones, your eye couldn't distinguish some of the details that worked before.

Anyways, it is an interesting problem and one that I don't envy designers for.

Font hinting can be terribly difficult (more art than science) and incredibly time consuming. Matthew Carter designed a custom font for us and I've been involved in the process of its creation / tweaking over the last few years. Everything I've seen makes me feel like TrueType hinting experts are like the digital equivalent of Swiss watchmakers. I'd love it if more font "programmers" (the guys actually creating the font, not designing it) would tell their tales.

I agree it was a fascinating look at the problem. However, the assumption in the article is pixels. Let me sum up.

Scaling artifacts occur because at smaller sizes the quantitization of the unit pixel overwhelms the details of the image. When I was a system programmer at the Image Processing Institute at USC (you know the source of that Lena picture :-) this was characterized as the frequency response of the display. So if you were to take a horizontal line across the pixels, and then plot their intensity vertically along a line (so x becomes the position in the line, and y is the intensity of the pixel at position x) then you can then do an FFT across those pixels and see the distortion in the visual signal from the source material to the displayed material.

Now the part that gets confounded in articles like this one is that the UX designer doesn't really want a 16 pixel icon, what they want is an icon that has a certain size with respect to the whole screen. Working backwards, lets say the icon ended up being 16 x 16 on a 1024 x 600 screen which had 72 pixels per inch. The icon is about 1/4" on a side (.22" but you get the picture). Now on a screen that that has 240 pixels per inch, that icon at 16 x 16 pixels is only .06" or nearly impossible to see, but if you keep it at 1/4" you get 60 x 60 pixels to work with.

So lets bring two things together, you do 'hinting' because the artifacts that are created by the quantitizing effect of pixelation cause you to lose information. As screen resolutions get denser the information lost goes down (less quantization, or more signal bandwidth is available) so once your signal loss from a straight mathematical shrink is acceptable in all required sizes your done.

Bottom line is that this won't be an issue when the minimum icon size is being rendered into a field of 128 x 128 pixels or more. Might take one more generation of screens.

The second thing is that while a designer can poke pixels to get an icon that looks good, so can the computer. One of the things you can do is compute the frequency 'footprint' of the image, then change the render until the render foot print is as close as you can get to the original. HP did this for their ink jet printer half-toning algorithm. In a 16 x 16 pixel space you could almost exaustively search it on a modern machine.

> The second thing is that while a designer can poke pixels to get an icon that looks good, so can the computer. One of the things you can do is compute the frequency 'footprint' of the image, then change the render until the render foot print is as close as you can get to the original. HP did this for their ink jet printer half-toning algorithm. In a 16 x 16 pixel space you could almost exaustively search it on a modern machine.

Cool! Do you have a link/paper/book?

http://www.dsi.unive.it/~auce/docs/celentano_spie97b.pdf

http://www.stanford.edu/~slansel/tutorial/Papers/Donoho/Imag...

Are exemplar uses of the FFT to analyze the signature and content of an image. Since a lot of work on this was done in the 80's I would expect some good summaries in the current texts on image processing.

Author of the article here.

If you read the closing paragraphs of the article, you will see that I do talk about the physical size of the final representation of the pixel-based icon. However, just because you can use more pixels on higher-resolution displays, it does not mean that you can just take a highly detailed vector artwork and display it.

Being able to display very intricate details for each icon is not necessarily the end goal. The end goal is to preserve the clarity, which is why smaller icons (physically, not pixelwise) should have smaller amount of detail compared to larger ones.

In your example, a 128x128px icon that occupies the same physical size on an extra-high DPI screen as a 16x16px icon on a lower-end screen can (mathematically) have 8 times as much detail along each axis. Just because this is possible to do without losing the signal quality on the level of individual pixels, does not mean that it is desirable from the UX / UI perspective.

You're right that in a world with varying pixel densities, it's not enough to just design an icon for a given pixel size. But physical size isn't the right design target either. An icon designed for a given physical size on a display close to the user's eyes won't work if the display is much further away.

So when you go from thinking about pixel size to thinking about physical size, you're going in the right direction, but you're not going far enough. The relevant metric is more like "the angle subtended at the user's eyes", kinda like how the "CSS pixel" unit works.

Now, given that it's almost impossible for software on the device to know how far away the user is, trying to design up front for that metric (angle subtended by the icon) is also almost impossible.

And even if you did know both the pixel density and the distance to the display, that still doesn't take into account the fact that users will vary in their visual acuity. The right design choice for a 20-year-old user holding the display close to their face is going to be dramatically different from the right choice for a 70-year-old holding the display at arms length.

You can't really design well for all those possibilities up front. The right answer has to involve allowing the user to adjust the "zoom level" to their liking. And that level of flexibility means that automated approaches (possibly something like freetype's autohinting, extended to work in color) are probably going to be a better approach than manual pixel tweaking.

This is actually a good reason to move away from pixel designs and towards vector graphics. An assumption made now is that there is one or maybe two resolutions at which a 128x128 icon is displayed, and this is true for iOS screens. But with a more heterogenous selection of screen resolutions and expected screen distances, the actual display size of a 128x128 icon is basically unknown.

There are two problems you are conflating. One is that low-resolution icons have visual artifacts, and therefore manual pixel hinting is valuable. In general though, this problem only crops up for very small icons, say smaller than 32x32. But as screen resolutions increase, this problem will get easier.

The other problem is that at small sizes, we want icons to be less detailed and therefore more recognizable. A quarter-inch icon two feet from the eyes should have very little detail. This is a problem that vector graphics are very suited for. One can specify a low-detail icon that should be used when the real size of the icon is below some threshold, no matter whether that screen space is 64x64 or 20x20. In a world where the screen resolution of an icon that size can vary by more than a factor of two, using pixels is the wrong approach.

The very meaning of the term “icon” implies a non-literal representation, and since there is no automatic way to transform high-res representation to low-res caricature, you end up with vector artists doing horrendous pixel art.

Pixel art is a very different medium from what they’re used to, and there are specific techniques that they haven’t learned, largely because they don’t even know such techniques exist. They don’t know how (or when) to antialias or dither by hand. They don’t know what banding is and why to avoid it, nor what selective outlining (“selout”) is and why they need it. They especially don’t know how to correctly choose a good, limited palette. All of these things taken together make for designers at best reinventing tools and techniques, and at worst making icons that suck.

But what can you do? Pixel art isn’t a popular medium, so the wealth of knowledge out there goes to waste. It’s such a pity.

Do you have any resources for beginners you recommend? (I'm not a designer -- just have a certain fondness for dying media, I guess.)

Absolutely! Though pixel art isn’t dying—the niche is small, but not shrinking, and there are artists who make a considerable amount in commissions, typically sprites and backgrounds for games.

I suggest you check out Pixeljoint[1]—coincidentally it’s down today for a server upgrade, but the community offers excellent feedback for new artists, and the tutorial section has links to some great resources. Pixelation[2] is a great community with many experienced artists from the pixel world and demoscene. You’ll also find a couple of tutorials on an older site of mine, Studio Purloux[3]. One is a general tutorial by my good friend Kevin Chaloux[4], an outstanding and highly regarded pixel artist; the other is my own introduction to manual antialiasing. That should be enough to get you started.

[1]: http://www.pixeljoint.com

[2]: http://www.wayofthepixel.net/

[3]: http://purloux.com/artwork/tutorials/

[4]: http://kaiseto.deviantart.com/

Thank you! Exactly what I had in mind. The attention to detail and tight constraints reminds me a lot of font design / hinting / etc.

I'm glad to see near the end the mention of high-density displays. When designing icons, a 64@2x icon should be different than a 128@1x icon. Although the former is technically at 128, it is going to be displayed on a high-density display at a smaller size, and care should be taken to simplify embellishments and details that will just make it look too detailed when viewed.

For icon designers out there, I'm curious how many are already aware of this distinction and are designing icons accordingly?

Isn't this a little bit of inefficient over-optimization. Sure auto scaled vectors look more blurred than hand made bitmaps. But the important question is: do normal people even notice the difference in today's screens? At the end of the post, the author concludes that not yet. But he doesn't seem to back it up. And I don't mean to back it up by comparing vector and manual icons for videophile designers. But actually a/b test it with real users.

I know I personally cannot tell the difference between the example comparisons in the post. Not sure my users would. I'll probably a/b test it with them at some point to be sure. Until then, my impression is that vectors are a net positive.

It depends what you are showing. Seriously some stuff just has too much detail and. Less detailed version works better - was doing this for a logo the other day and there were three versions for different scales; all worked well but the larger ones were closer to the full logo.

Oddly the .ico format allows different versions for different resolutions, unlike most ther formats.

I use a SIMBL extension to bring OS X 10.6's colorful Finder sidebar icons to 10.7. I have always been meaning to improve its source code because it simply scales the large versions down.

The difference is irritating and clearly noticeable for e.g. the "Documents" icon if you compare it to the "Go" menu. And it's not because the big versions are bitmaps, it was mostly the missing outline and lack of contrast.

(I still find them much faster than the monochrome versions (and with a smile) :))

The Finder's "Go" menu is really a good example of tiny, clear icons.

I'd like:

1. native support for optional manual hinting vector icons

2. native support for optional auto-hinting vector icons

Auto hinting is not the ultimate solution, but it can get you part way there, just like with fonts.

> Auto hinting is not the ultimate solution, but it can get you part way there, just like with fonts.

Even without auto-hinting, it still boggles my mind that "desktop" vector formats don't seem to support hinting at all: I recently discovered there is no possibility of hinting in SVG, therefore SVG fonts (fonts described using SVG shapes) can not be hinted at all, that's completely insane.

YES. Given how long we've been building up to resolution independence, given the already long standing real-world examples of vector object hinting provided by fonts... it's amazing that there seems to be little work in this area and less work in terms of actual standards/implementations.

This is an area Apple is perfectly, ideally positioned to execute and lead on.

EDIT: I wonder if one could implement vector icons as fonts in order to properly hint them.

> I wonder if one could implement vector icons as fonts in order to properly hint them.

That's exactly what is happening these days with custom font embedding having become practical (in web pages): http://somerandomdude.com/2010/05/04/font-embedding-icons/ (that was in 2010, but this thing is really gaining traction these days following the release of "Font Awesome" for Twitter's Bootstrap[0])

In desktop OS, that is in fact a very old technique, that's why the Marlett font exists in Windows [1].

It does have a significant inconvenient though: the icon can only have one color for the glyph and one for the background. This provides a crisp look but lowers the expressivity of the icons. On the other hand, if the color scheme changes for some reason (or can vary from one page to an other), it is very easy to match the icons's color scheme to that of the application.

[0] http://fortawesome.github.com/Font-Awesome/

[1] http://blogs.msdn.com/b/oldnewthing/archive/2012/01/16/10256...

I've used custom embedded icon fonts on websites as well, but I was actually thinking of the more complex ui components through layering. I.e. button background/foreground combinations for buttons.

I suspect that there would be a whole host of other issues (rending of baseline location varying by a pixel, etc.).

SVG fonts are a failed font format, which is why Mozilla refused to support them. They had a brief use as iPad fonts but that's dead now.

But doesn't SVG support CSS Media Queries? That would make it more than possible to support showing/ hiding appropriate elements/ layers according to the current dpi, width/ height, orientation or whatever?

Haiku OS uses vector icons in a a format called HVIF, a much more efficient format than SVG:

http://haiku-os.org/docs/userguide/en/applications/icon-o-ma...

https://www.haiku-os.org/articles/2009-09-14_why_haiku_vecto...

This is an interface design/hardware issue, not a display optimization issue.

The article makes the bulk of the case for pixel optimization while discussing very small icons, and that's true, but it's a red herring. Interfaces should never rely on users being able to identify or interact with icons that are 16x16 pixels. At 64px, all of the icons seen in the article can be auto scaled successfully (in gimp, cubic transform): http://imgur.com/a/DOAyW

What we really need is to stop building hardware that demands 16x16 pixel elements, and to stop building interfaces that provide them. With high dpi screens, even character hinting becomes silly (or even without high dpi, I disable hinting on my 22" 1920x1080 screen because I like consistent letter spacing).

Pixel optimization experts may still have a place in the future, but it's likely in the same boat as audiophiles and $1000 HDMI cables.

Great, detailed post. I think situations exist today where vector icons can be a good solution; however, the promise of design once, deploy everywhere for artwork and UI that requires attention to every detail ... the rendering/display tech is not yet available at scale.

I think an orthogonal challenge is convincing cross-functional peers that visual execution and all of the design details have a huge affect on the user experience, the product, and therefore the business. In my experience, it's rarely a straight-forward or painless debate.

Just like with HTML/CSS and responsive design, you can use media queries in SVG images. That way you could do the optimizations suggested in the article, including changing colours, hiding details, etc. Take a look at the demo links at http://my.opera.com/ODIN/blog/2009/10/12/how-media-queries-a...

As far as I know there's still a lack in tooling though, so you might have to write some "code".

The solution is in SVG itself. Set the id='s properly, and we can then do a simple map of existing hinting terminology directly into the DOM. Want less density at lower resolutions? Create a low-res layer within the SVG specifically for this case. The strength is entirely in the language used to declare the hinting; this can be directly incorporated in SVG, and thus made accessible to designers immediately (Inskcape -> Ctrl+Shift+X, start your engines..)

Symbian used SVG for all icons, for various screen sizes. Never looked especially good, especially so on the lower DPI screens.

So it would seem the ultimate future-proof solution is to have multiple vector icons with different levels of detail, each targeting a particular set of actual rendered sizes. Then, when the platform vendor doubles pixel density on you, you simply use your current 32x32px-targeted vector design to render the new 64x64px icons.

Not sure why this can be a "solved problem" with fonts (mostly) due to intelligent hinting.

Is there nothing like "Hinting for SVG" or an SVG equivalent to "Multiple Master" fonts (https://en.wikipedia.org/wiki/Multiple_master_fonts)?

Fortunately all of this will be moot in a few years, when high-dpi becomes the norm.

Some of the examples he shows are much worse than reality. You can have outlines that don't increase in width for larger sizes.

I wonder how that works out with the crazy new ipad resolution. If that's the future, maybe we can have those one-size-fits-all vector icons eventually.

thorough as hell, bookmarked for later. good find.

The answer is to use HTML5 canvas instead of SVG, and create your icons as a JavaScript algorithm. Canvas code can become vector if you utilize the scale() function. I've done this for the icons in one of my web apps and it's a superb solution.

If there was some way to export a vector drawing as a JavaScript algorithm, or some semi-standard way to process an SVG image to Canvas then it'll become the defacto icon solution for the forseeable future.

Can you please show an example? This is interesting.

I want higher DPI and it's an "easier" albeit expensive solution.

Reply on news.ycombinator.com