The problem with vector icons is that they don't really scale as well as people seem to think.
Just because you can rasterise it at any size, doesn't mean that the resulting icon makes sense at that size. When icons are really small you usually want a simpler version of the same icon for it to remain recognisable.
To properly handle this you'd need either multiple versions or a vector format that can scale the amount of detail with the size. In either case you'd need to ensure that the rendering has pixel-perfect results at small sizes so it doesn't become a blurry-mess, kind of defeating the purpose of using a vector format.
Vector images work great for large icons, but for small ones they fall short.
Someone else has mentioned that HVIF supports level-of-detail hinting.
This is renderer-dependent (as it's a relatively new feature), but SVG alsp supports altering the vector by scale via CSS media-queries. Oversimplified example:
HVIF does have level-of-detail hinting, and I believe it also explicitly defines the pixel exact correct rendering although given the small audience I won't swear they didn't miss anything.
So you can add a shape which just isn't rendered at all in lower resolutions. For example suppose the icon for your app is a stylised steam locomotive and you want to add your company logo on the side of the tank, this detail will look cool at 512x512 and maybe if the logo is simple at 128x128 but it will just be a blotch on the 16x16 icon - so HVIF lets you specify that the logo isn't added at all below say 128x128.
I agree with the principle of what you're saying. A striking example from Windows XP is that is that folder icons are at a jaunty angle at 32x32 and higher but flat on at 16x16.
But what if you're looking at 48x48 icon on a screen with triple the pixel density in each direction? Surely you'd still want an image with with the same amount of detail as you'd normally get in a 16x16 icon, even those few details are rendered with a high pixel count – basically you're running into the resolution limit of your eyeball. And this is a very common situation now because of course phones have a far higher pixel density than most traditional monitors.
So there is potentially benefit in vector icons even though, as you say, you still need two or more versions with different levels of detail.
> For 32 px and above, vector images are a valid choice.
Well, that depends on your screen's density and how much you care that your design is aligned to the pixel grid. For a very long time most iOS icons were hand-aligned to the pixel grid, and when they switched to vector icons in iOS 13 they looked awful because they were aligned poorly.
Yeah, dedicated raster 16x16 and 32x32 versions and then a vector version if larger icons are required seems like the best approach.
I understand what they're trying to do with including the icon as metadata, but since they control the filesystem format as well, couldn't they just increase the storage available so they could store an extra kb or so? I'd expect that on modern hardware, reducing the number of reads by stuffing bytes into odd corners of each file's metadata is far less effective than just arranging a block of data to be read all at once.
At sizes like 32 px, you still want more control over line widths and details than a regular vector format grants you. For images that small, you still want to emphasise some things more than others.
The 'problem' with vector icons as well is pixel boundaries and anti aliasing producing blurry lines.
Say you have a 16x16 SVG, and have a single-unit ("pixel") line down the middle. Render that SVG at 16px, and you get a single nice crisp pixel. Render it as 20px and now your "1px" line is like 1.3 pixels, which isn't going to look good.
The problem is worked around with raster icons by just not providing the flexibility that a vector provides.
Rasterise your icons to fixed sizes that you’ll use in your application. Of course, this has its own set of compromises (namely the inflexibility) that may or may not be acceptable for your use case.
You can have a vector icon that doesn't have the smudge issue over a set of reasonably chosen rendering sizes (through specified pixel-exact rendering and alignment).
And said vector icon will still look a whole lot better scaled from supported/optimized 16x16 size -> less favored 20x20 size than a raster icon, even if it isn't absolutely perfect.
To rasterise your icons to fixed sizes, you need to scale the original source (possibly vector-based) image to that size. That scale operation, while one-off, has the same problem as the dynamic runtime scaling of vectors.
> The 'problem' with vector icons as well is pixel boundaries and anti aliasing producing blurry lines.
Level of details is also a major issue when scaling down. Nice features of an icon at large size become sub-pixel when scaled down and their rounding up or down messes with the icon and destroys its balance.
Just use the simple version at all sizes. Why does an icon need fine detail? Icons are abstract representations, like letters. Do you insist on adding ornamentation to your letters at large font sizes?
That's a great analogy. For scaled outline fonts to remain legible at low resolutions, they have a sophisticated hinting system (it even has a little virtual machine!).
I'm sure if someone developed a hinting VM framework for vector icons (that wasn't patent-encumbered like half of the font ones), it would do a lot to help convince people that special low-resolution bitmaps weren't necessary for tiny icons to look good.
Actually, fine font serifs are visible only in large sizes. Curves also can be more more finely rendered and gain a lot from bigger size/better resolution.
People do recommend switching between serif and sans serif typefaces, depending on the size of the text. Admittedly, it often goes the other way—-sans serif at bigger sizes—-but the idea is the same: some things look better at a particular size.
Indeed. The best icons are caricatures, designed to fit the resolution they are being displayed at. "About Those Vector Icons" is a good read that shows why "hinting" just isn't enough.
Both of those 16x16 icons look like blurry messes to me. If they weren't sitting next to 6 other larger pictures of a tape recorder, drawn in the same style, there's no way I'd have any clue what it was.
the Adwaita icon theme uses vectors for their icons[0], but they create multiple different SVGs at different sizes for the different sized icons (if that makes sense). For example, here’s one[1] icon.
You are right, there are some cases where vector graphics are not as good as traditional bitmap graphics (especially when the vector graphics weren't build for the size they are being rendered at).
But as soon as you don't know the pixel density of the target screen, vector graphics produce much better results compared to the time you would have to invest in perfect bitmap graphics.
So if you are designing a website (potentially viewed on devices with different pixel densities), vector graphics are likely to outperform bitmap graphics.
I wonder if it would be possible to create a vector image format that could identify the shapes and paths that are critical for legibility, and then write a scaling algorithm that is able to produce crisp results at 16x16 from the vector source.
On the outset that feels like a really hard problem.
The starting point would be to look at font rendering, especially hinting. I'm not sure if any of the popular font formats allow for adding more strokes when rendering at larger sizes, so they may not have much ability to scale image complexity, but they definitely have what you need to optimize for legibility at small sizes.
At risk of sounding like the guy who throws the machine learning hammer at everything, I actually wonder if a tiny CNN would not be a great solution to this. If you have a bunch of example icons tuned for low resolutions, as well as the vector art, you could potentially train a network to do a better downscaling job specifically tailored for icons. The point would be that the CNN weights could be common to all icons and not necessary to store in each file. Since the "domain" of icon design is quite restricted in terms of dimensionality and colour space, I bet a pretty small CNN would do a great job.
Another problem is that vector icons cannot capture every type of icon. For example, icons that were generated using a ray-tracer.
So instead of using a vector format, we should probably use an executable format instead to obtain full generality. Postscript does something like this.
The original truetype font was vector based but had to be legible at small font sizes. Apple created hinting in the late 1980s that worked well on macs. I believe Microsoft added better rasterization about a decade later.
The "small font problem" was practically unsolved until Adobe invented and patented declarative hinting in Type 1. Before, bitmap fonts were used. The bytecode stack machine for hinting used in TrueType, designed by MS/Apple, was specifically designed to not infringe on Adobe's patents.
Only when hinting became an option did vector font representation become viable at all for printing. Digital vector font display was accomplished much later.
While you are correct about Adobe Type 1 fonts, you are incorrect on display fonts. Apple System 7 had vector display fonts. There were issues on windows which is why Microsoft (and likely Adobe) improved TrueType. Adobe later responded with Adobe Font Manager which is likely what you are referencing.
With modern retina displays it's not really an issue. 16x16 icon on iPhone 8 display will have a size of 1,2 mm. 10mm icon will have 128x128 resolution with enough pixels to provide every detail.
Except high density displays are not really that common outside smartphones and the Apple world. It's probably safe to say most people still work on regular 1080p monitors at 90-100 dpi or at best on 1440p with slightly higher dpi. So an SVG with design resolution of 512×512 will look like a blurry mess when scaled down to 16×16. We'll get there eventually but optimising for low-density displays is still a very valid and reasonable thing to consider.
Even smartphones sometimes have lower-resolution displays. 720p resolution is still rather common at the low end, and that's something where a 'pixel perfect' 16x16 icon can still make some sense.
In that case, the problem seems a bit exacerbated by using a renderer that is very bad at rendering at small size. I'm sure you could render that to be a bit less of a jaggy and blurry mess.
IMO this is only an issue insofar as low resolution (~96 PPI) displays go. Of course you can just about always make better use of pixels by hand, but its not about making the absolute best possible use, just getting the job done and looking nice. How often do we even have 16x16 pixel icons in modern UIs?
or don't use low resolution displays. 5K displays are currently run of the mill. 8K displays are on their way and may be the end of the road for the resolution race. Printers went to what 1200DPI?
How many pixels is a 0.5CM icon at 8K? A dell 8K display at 31.5" has a PPI of 279. at 27" it'd be 326. Does vector scaling work at 326PPI?
If so any effort is wasted handcrafting icons. Simply wait 3-4 years.
Sorry you're right. 4K Is run of the mill now. 5K is not quite. But the point still stands, technology improves. It only needs to improve to a certain level before it goes beyond human perception. That will happen in a few years.
Any efforts trying to adapt to the limitations of current technology are wasted.
Just because you can rasterise it at any size, doesn't mean that the resulting icon makes sense at that size. When icons are really small you usually want a simpler version of the same icon for it to remain recognisable.
You can see it clearly in the examples used in the article for the 16x16 icon. Compare the bitmap version (https://www.haiku-os.org/docs/userguide/images/apps-images/i...) to the vector version (https://www.haiku-os.org/docs/userguide/images/apps-images/i...) , the bitmap version is specifically made for the low resolution and is still very clear, the vector version is a blurry mess.
To properly handle this you'd need either multiple versions or a vector format that can scale the amount of detail with the size. In either case you'd need to ensure that the rendering has pixel-perfect results at small sizes so it doesn't become a blurry-mess, kind of defeating the purpose of using a vector format.
Vector images work great for large icons, but for small ones they fall short.