Hacker News Reader

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:

  <svg viewBox="0 0 48 48" xmlns="http://www.w3.org/2000/svg">
    <style>@media (max-width: 24px) { .detail { display: none; } }</style>
    <path d="basic icon here" />
    <path class="detail" d="extra icon details here" />
  </svg>

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.

> HVIF does have level-of-detail hinting

Yeah, the Icon-O-Matic application documentation[0] has some more info on this.

From the site:

> With the LOD you control the visibility of a shape depending on its size.

> That way, you can leave away details of an icon that look good on a bigger icon, but maybe not so much on its smaller version.

> The LOD is not only for leaving out detailing shapes, but also to e.g. change the stroke width at different sizes, if you feel that's needed.

> Simply duplicate a shape, make your changes and set both of their LOD settings to show either one or the other.

Looks like somewhat similar to CSS media queries.

Edit: Looks like[1] SVG has a similar feature too.

[0] https://www.haiku-os.org/docs/userguide/en/applications/icon...

[1] https://twitter.com/tzmartin/status/688950091063771137

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.

I believe the best idea is to have “hand-crafted” bitmaps for (96 ppi) sizes 24 px and less. Especially 16 px icons are very hard to get right.

For 32 px and above, vector images are a valid choice.

Now we just need a file format that combines all this. :)

> 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.

> Now we just need a file format that combines all this. :)

TTF?

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.

This is the reason common icon sizes are spaced in the increments they are: 16, 24, 48, 64, 72, 96, 144, 192, 256, etc.

There isn't really a "good" solution to this other than the above system (and it's not solved by rasters in any way)

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.

So I don't really see this as a "problem".

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.

Sorry, I meant creating each size 'manually', or at least pixel-pushing everything back into place.

> 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.

> Icons are abstract representations, like letters. Do you insist on adding ornamentation to your letters at large font sizes?

Letters have that exact issue, vector fonts were essentially unusable on computers until font hinting was invented.

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.

https://www.pushing-pixels.org/2011/11/04/about-those-vector...

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.

[0]: https://github.com/GNOME/adwaita-icon-theme

[1]: https://github.com/GNOME/adwaita-icon-theme/blob/mainline/sr...

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.

On this note there is this interesting "Responsive Pixel Art" project [0] that quite resonated here in the past [1].

[0] https://essenmitsosse.de/pixel/ [1] https://hn.algolia.com/?query=essenmitsosse.de%2Fpixel%2F&so...

Whoa, that's amazing!

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.

It sounds like you're describing font hinting: https://en.wikipedia.org/wiki/Font_hinting

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.

Oops, I meant to say that TrueType was designed by MS/Apple to avoid Adobe's patents, not "MS/Adobe". Fixed the typo; thanks for the correction!

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.

Most < 500€ laptops I see in stores are still 1366*768 - and that's what people buy most - eg stuff like this : https://www.ldlc.com/fiche/PB00277098.html

Yup, 1366x768 is the most popular desktop resolution, although 1920x1080 is closing the gap:

https://gs.statcounter.com/screen-resolution-stats/desktop/w...

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?

you'd still want a custom icon for small sizes, because it's not about the resolution but perceived icon size. It's similar to this illusion https://www.independent.co.uk/life-style/health-and-families...

if you scale the image down, you should see Marilyn, even at high resolution

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.

This feels like the tail wagging the dog.

Please, please show me examples of 5k being run of the mill. That claim needs evidence.

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.

Here's a 4K display from Phillips for $235 https://www.amazon.com/Philips-276E8VJSB-3840x2160-UltraNarr...

Edit: and a DPI calculator and reference. Notice all the old low-res displays and how most of them are behind us. https://www.sven.de/dpi/

These stats suggest 4K isn't particularly prevalent:

https://gs.statcounter.com/screen-resolution-stats/desktop/w...

Infact, it seems to suggest that even 1366x768 comprises the majority.

So, can you quantify 'a few years'?