500 Byte Images: The Haiku Vector Icon Format (2016)
blog.leahhanson.us
blog.leahhanson.us
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.
Deep learning suggests differently?
Or something like the hinting bytecode in certain TrueType fonts?
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
> ... 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.
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.
Edit: also note that svg can have resolution-dependent details : see last discussion on hn https://news.ycombinator.com/item?id=22374744
Saving space is well and good but for icons it’s secondary to how clear and usable the images themselves are.
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.
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.
https://www.pushing-pixels.org/2011/11/04/about-those-vector...
“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.
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.
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?
"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.
Physical books are obsolete for not changing without your consent every 5 seconds. /s
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.