hckrnws
A resonable icon format would be a vector file plus (at least optionally) 16 and 32px bitmap images. A 16x16 px icon is still common (eg toolbar buttons at desktop resolutions lower than 4K) and as evident by the article there is no way of rasterizing a vector image to 16x16 and preserving anything but a blurry mess. At least not without using a very clever (AI could possibly do it) rasterizer.
The 16x16 representation is often completely different from the vector or 64x64 version. If you draw a clock, the large version is 3D has numbers and 3 hands. The smaller versions is 2D, has 2 hands and no digits.
It might just be badly chosen example images, but the images in the article make a good case to me that even up to 64x64 bitmaps are superior. In the upscaled 32x32 computer icon the bitmap has a much better keyboard with defined keys, compared to the SVG and HVIF where it's a blurry mess. Similarly in the icon of the tape recorder the buttons (one of the key features of a tape recorder) are much more recognizable in the bitmaps from 16x16 up to 64x64 because the outlines are always a pixel wide, while in the vector they get lost in antialiasing on anything smaller than 128x128.
Those might not be issues on more stylistic icons like many logos. The HN logo works fine as a single vector, same for the github icon or the wikipedia logo. But for more complex icons that depict real-world objects making vectors work over a range of scales is really hard
Many of us look at https://github.githubassets.com/favicons/favicon.svg at 16x16 every day, and wouldn't call it a blurry mess.
I think that's because our screens all have 2x pixel density, so the icon is actually a half-size 32x32 image.
HVIF supports having different shapes at different levels-of-detail in one file.
The thing is that at 16x16 target res it's probably not worth having another vector representation: you can just as well store the raster at that resolution.
> At least not without using a very clever (AI could possibly do it) rasterizer.
Or something like the hinting bytecode in certain TrueType fonts?
Making it hints instead of a 16x16 raster could save some weight. But 16x16 isn't a lot of data. Saving half of it but having to do the kind of magic trickery that goes on in TrueType seems a bit excessive
> there is no way of rasterizing a vector image to 16x16 and preserving anything but a blurry mess.
Deep learning suggests differently?
So instead of 5kB bitmap we'll do a 768B vector + a 5GB diffusion model, plus waste 20 seconds just to render it.
You got me on the model size but speed wise there are algos that run fast
Those are pretty fast but I suspect spending nearly any amount of time running some model to spit out an icon is too much time. I should be able to load a directory with 1000s or 10s of thousands of files extremely quickly.
24x24 and below still require special treatment because pixel grid alignment becomes really important. The tape recorder image demonstrates this well: the raster 16x16 looks way better than the vector. I wonder if it would generally be better to store these tiny sizes as bitmaps in the container.
Yeah, I'm suprised the original article didn't mention that. One of the main reasons that smaller icons are stored as separate files is that they need to actually be designed differently, not just scaled down.
Haiku icons have support for Level of Detail.
Link: https://www.haiku-os.org/docs/userguide/en/applications/icon... under "Level of Detail"
> If you use the standard bitmap icon formats, you’ll probably store them in their own files, separate from the files that use them. In order to display each file in a folder, the operating system will need to read the metadata for the file (including its name and file type) and then read the icon file for that file type. If the icon file were so small that you could store it in the same place as the file metadata, then you could save a read from the hard drive – you could get the metadata and the icon all in one read.
> ... it could be a significant performance gain to halve the number of disk reads even if rendering a vector image takes longer than rendering a bitmap.
Surely another option would be to cache all the filetype icons in memory and thereby only read them once? You could still use this cool vector format and get the best of both worlds, so each icon would be small and would be read only once, and you wouldn't have duplicate icon data all over the disk. And then if you wanted to change the icon associated with a particular filetype, you wouldn't need to update every single inode for files of that type.
I've always thought SVG was a terrible format and I hate that it has become synonymous with "vector". The only thing it has is interoperability because of XML. Any binary format would be more performant. Then we have Inkscape that is basically a SVG editor so it has to stay compatible with the SVG standard. Proprietary vector image editors like Affinity, Illustrator, and Corel Paint all use their own formats, so they can add and change any functionality they want. It's just Inkscape that's confined to SVG.
That said, I don't think a single vector file is a good solution for icons. If you take a look at Windows 98 icons[1], you'll see that many icons are manually re-drawn for lower resolutions, which is something that ICO format can do which nobody else can do for some reason. A simple example is the calendar icon. Because a calendar has a "grid" for all 7 days of the week, it would need to have 6 vertical lines, which would look too busy in 16x16. So the 16x16 icon just uses fewer grid lines instead of turning everything into a blurry mess.
Anecdotally, I've tried using 16x16 pixel icons on the web before, but fractional scaling made them look bad on my phone.
SVG has a lot of warts, but it actually has two big things going for it: it's everywhere, and it's DOM-programmable. Anyone who knows js can start animating SVGs the same way they animate the DOM. It is somewhat more primitive, given how z-ordering is source-code dependent, and its weird compound attribute values for things like transforms. It's also true that if you try to code seriously with raw SVG you're just going to redefine a new library like D3 or Three.js or chart.js, but worse.
Inkscape is not really "confined" to svg, because saving to pure svg is lossy. Only svg with extra specific inkscape metadata is lossless- clearly legit svg, but with specific bits under the "sodipodi" namespace IIRC.
Edit: also note that svg can have resolution-dependent details : see last discussion on hn https://news.ycombinator.com/item?id=22374744
As mentioned elsewhere in this thread, Haiku solves the detail issue by allowing shapes/paths etc to be marked to only render in certain resolution ranges.
This is great and all but how do they look? The only good example is the tape recorder which imho looks less and less like a real tape deck at larger sizes; the shape of the tape is noticeably distorted and the curves in the shape of the body are unrealistic.
Saving space is well and good but for icons it’s secondary to how clear and usable the images themselves are.
One of my favorite articles on this topic, "About those vector icons", goes into this issue and many more flaws in much more detail. There's nothing fundamentally wrong with vector icons, but it's not all that's needed for a one-size-fits-all solution.
https://www.pushing-pixels.org/2011/11/04/about-those-vector...
showing some image using fewer and fewer pixels is like trying to summarize some text using fewer and fewer words, at some point it requires intelligence, at another point it's an artform
Appropriate for an operating system called Haiku ;)
Haiku has an extensive UX and design guidelines document - including meticulous rules for icon design. The tape recorder looks that way because it adheres to those guidelines, not because of a file format.
Can you provide a link? The only thing I found is https://www.haiku-os.org/development/icon-guidelines. I wouldn’t call that extensive.
I think Android’s (https://m2.material.io/design/iconography/product-icons.html...), Apple’s (https://developer.apple.com/design/human-interface-guideline...), and Microsoft’s (https://learn.microsoft.com/en-us/windows/apps/design/style/...) are more detailed than that.
(And yes, that’s comparing to the work of huge companies, but I don’t think that matters for deciding whether to call this ‘extensive’)
I also do not rule out that the tech choices they made (partly) drove the guidelines. It doesn’t make sense to proscribe things the OS cannot display.
I found a repo of the Haiku icons in various formats: https://github.com/darealshinji/haiku-icons
Typically how they look is up to the designer, they can decide how many small details they want to put in to make the icon look better at a larger scale. Haiku seems to have gone with a kind 3d clipart style that isn't highly detailed.
When the format was developed nobody was rendering icon's at 128x128. PC Icons were 16x16 or 32x32. Mac's might have supported bigger icons, but it was still a long time long time before screen resolutions necessitated 64x64 icons.
I believe NeXTStep used 64×64 icons from the beginning (1989), although they always included some margin.
How so? It's obvious it was drawn to look like that. It's not a deformation.
[dead]
Perhaps I'm misunderstanding something but... does this mean that when you say, create a text file or PDF on Haiku the application creating that file is responsible for copying its icon into the new file's metadata? i.e. if I make a directory full of 1000 text files then I've also created 1000 duplicate images?
I think you’re misunderstanding things. FTA:
“If you use the standard bitmap icon formats, you’ll probably store them in their own files, separate from the files that use them.”
⇒ i think they’re talking of having to read the same data again and again, and then try to minimize the number of blocks read from disk.
Of course, reading the icons again and again is the MVP implementation, but not necessary. They could create a cache of icons. Even if they don’t, the file system cache would significantly decrease the number of actual disk reads.
It always amazes me that there is no binary encoding available for SVG.
Every few years I end up dealing with an SVG and get curious and look it up again to find nothing has changed.
Makes perfect sense to me Haiku would want a binary format.
Wait, did I understand this correctly? Every file entry in the file system has a copy of the icon? What happens if you want to change the icon?
So why not use the SWF file format? It's a well-documented standard, and is binary and compact.
Aside from it being an obsolete proprietary format, what subset of swf should they implement?
It's extremely complex for an image format, and many of it's features seem a little out of scope. Not much use for an interactive animated icons, and the scripting bytecode seems inviting a security disaster?
Ever looked at the SWF format before?
It's a series of tags. Things like DefineShape, DefineMorphShape, DefineSprite (Movie Clip), DefineText, DefineBits (image), DefineBitsJPEG2 (jpeg), DefineButton, DefineFont2, PlaceObject2 (placing the shapes onto the stage to define a frame), RemoveObject (removing shapes from the stage),
Then Flash 8 added in graphics filters and blending modes. So movie clips can have filters applied like Blur or Outline, then use Additive blending so that explosions can light up the scene, things like that.
If you want to define a simple graphics format that is limited to one frame, and has no scripting, you could use only tags DefineShape, DefineSprite, and PlaceObject/PlaceObject2 just to place vector objects (without bitmap fills) on a scene. If you want to support the use of bitmap fills, you add in the image tags DefineBits and DefineBitsJPEG/DefineBitsJPEG2.
"obsolete" is meaningless.
"proprietary" too, because it is well-documneted.
The subset that is only necessary for vector images, obviously. Nothing beyond a single frame is needed. Since it's a TLV format, renderers can ignore anything they don't need, which includes the interactive and scripting features.
> "obsolete" is meaningless.
Physical books are obsolete for not changing without your consent every 5 seconds. /s
Crafted by Rajat
Source Code