
500 Byte Images: The Haiku Vector Icon Format (2016) - cosmojg
http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html
======
Aaargh20318
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.

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...](https://www.haiku-
os.org/docs/userguide/images/apps-images/i-o-m-bitmap16.png)) to the vector
version ([https://www.haiku-os.org/docs/userguide/images/apps-
images/i...](https://www.haiku-os.org/docs/userguide/images/apps-images/i-o-m-
vector16.png)) , 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.

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

~~~
myfonj
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/](https://essenmitsosse.de/pixel/) [1]
[https://hn.algolia.com/?query=essenmitsosse.de%2Fpixel%2F&so...](https://hn.algolia.com/?query=essenmitsosse.de%2Fpixel%2F&sort=byDate&type=story)

~~~
vesinisa
Whoa, that's amazing!

------
dahart
> The goal of the Haiku Vector Icon Format (HVIF) is to make vector icon files
> as small as possible. This allows Haiku to display icons as several sizes
> while still keeping the files small enough to fit into an inode (i.e.,
> inside a file’s metadata). The goal of keeping the icons in the metadata is
> to reduce the disk reads needed to display a folder – it allows each file to
> only require one disk read to display.

This is a great goal, a very cool file format, and a very nice article!

That said, my main worry with this approach is that it might not be comparing
or addressing the most common production workflows, which typically pack many
icons into a single compressed file, and only unpack them in memory. When you
pack multiple icons, you amortize all of the file reads into a single one.
It’s extremely common in games, web, and even desktop apps, to also pack the
images or other assets that icons represent into compressed files.

If you do pack your assets into zip files on disk, then it’s possible to lose
disk space by converting to a binary icon format that might be less
compressible, with no real gain in terms of disk reads or disk seeks -- and if
you separate files instead of packing them so that you get icons in your
inodes, you might be increasing the number of disk seeks & reads considerably.

~~~
waddlesplash
Storing the icons in inode attributes is just one use of icons on Haiku;
plenty of applications embed them as resources (i.e. in a data section of the
binary), which is more or less what you are describing here.

~~~
dahart
Sure, I understand you aren't forced to store them in inodes, just pointing
out (since it's part of the sales pitch here) that doing so might have
unintended consequences since people don't usually load small icons from many
separate files or web requests. It seems like a savings if you assume using
single separate files, but if you store your assets in a zip file, then
switching to keeping them in inodes might actually slow down the app. All the
production games and web apps I've ever seen and/or worked on personally store
many assets packed into single file.

It is worth thinking carefully about the tradeoff here. You are taking a
functionality hit compared to SVG, and adding a new indirection and more tool
dependencies to your pipeline in order to use HVF files. Ideally the payoff
should be worth the effort, but if you zip all your SVG icons, how often is
the compressed data averaging considerably more than 500 bytes per file? I
just checked Google, and the first hit for free SVG sets is Feather, a 132kb
zip file containing 282 icons, which clocks in at 480 bytes per icon on
average.

Regarding storing icons in the data section of the binary, that is certainly
one way to pack assets, but not one I would use or recommend personally. That
locks you into shipping a binary if you want to update assets, it doesn't
apply to web dev, or scripting languages, and it's pretty OS/platform
specific. Typically what I've seen in production really is some kind of zip-
like container file that is compressed and loaded separately from the
application.

------
Crestwave
Previous discussion:
[https://news.ycombinator.com/item?id=12420763](https://news.ycombinator.com/item?id=12420763)

------
b0rsuk
Vector images optimize for file size and flexibility. This is good for non-
standard displays and network.

The network advantage is hard to disprove. But which has lower total
computation cost?

A bitmap is created once, and the idea is very basic - you have a grid of
pixels. The good part is that it's simple to use it. A vector image is a
recipe for making an image. More calculations have to be done client-side,
times the number of clients. Clients have to do the work the server didn't
want to. You could say a bitmap is a compiled vector.

I think an ideal solution might be treating vectors as a source code. A web
server would receive a request, including display size. Then it would
"compile" the vector image into a bitmap and send the bitmap of the right
size. And cache the image, so if another user with the same display size asks
for the image, it's ready. Few people resize the browser window often. For the
same reason, I think code highlighters shouldn't use Javascript on client
side, unless the code might change (like, an in-browser REPL or pastebin).

Am I being misinformed? Pedantic? I like vector images, but would like to
learn if my affection is justified.

~~~
thedirt0115
They may not resize the browser window often, but when they do, it fires a lot
of events with a lot of resolutions depending on how exactly they move the
mouse to the desired position. Try opening your browser console, paste the
code below, then resize a few times and see how many events you get.

    
    
        window.onresize = function() { console.log("resizing!"); };
    

You could do various techniques like detecting the start of resizing and
waiting for it to settle down before requesting the new image, but still, I
think you may be underestimating how many resolutions there are out in the
wild :)

------
rcarmo
Haiku is full of little interesting design decisions like this. I would _love_
to have it running on a laptop (nearly there) or a Raspberry Pi (sadly, not
likely to happen soon, because the initial ARM developments sort of shunned it
and it's taken them a good while to re-focus).

~~~
waddlesplash
Haiku's goal is being a full-fledged desktop/laptop OS, not a "mobile" OS; and
most laptops and desktops right now are all x86, so that's what we primarily
target.

What's preventing you from running it on a laptop now?

~~~
rcarmo
Proper power management and Wi-Fi. I have a Chromebook with Ubuntu that has
well-supported OSS drivers but which won’t boot Haiku at all.

~~~
waddlesplash
Yeah, proper power management is not likely to happen in the near future; it's
a big task and nobody is working on it, due to ENOTIME.

Wi-Fi may be more reasonable, but we still depend on FreeBSD for that, so
we're still behind Linux. What chipset do you have?

What do you mean by "won't boot Haiku at all"? No bootloader? Stuck on splash
screen? Kernel panic?

~~~
wtetzner
What does ENOTIME mean?

~~~
kazinator
Probably a nonexistent POSIX _errno_ constant, corresponding to a nonexistent
message like "No time available".

------
DagAgren
Absolute love minimal image formats. There's just something very satisfying
about them.

I created this one: [https://blurha.sh/](https://blurha.sh/)

------
willvarfar
The idea of storing the icon in the inode is interesting.

Conventionally, when displaying a folder, a file manager identifies the _type_
of each file, and then looks up the appropriate icon.

Does Haiku instead display whatever icon is in the inode? Could a
wordprocessor document masquarade as a spreadsheet, and such?

I can't think of any security implications of this, nor think of any real
mischief that a developer might cause, but I also can't think of any big
advantage of it either. What use-case for having the whole icon in the inode
instead of just a mime-type that is then used to look up the (already parsed,
and shared) icon?

~~~
squiggleblaz
Even Windows has resources, including icons, inside the exe file. Obviously a
bit different (it's not in metadata, it's in the actual executable) but the
idea that a single file named PerfectlyHarmlessPhoto.jpg.exe could have an
icon of a jpeg file turns your computer in a botnet client is not a novel one.

Afaik in contemporary Mac OS, you have a directory with certain files in it.
I'm not sure if anything prevents you from naming the directory
PerfectlyHarmlessPhoto.jpg.app and giving it a jpeg icon. You would need to
get the user to extract an archive first, which may be more or less difficult.

I think the Linux practice of having a separately identified file provide the
icon is relatively rare. (I just checked Nautilus and ROX-Filer, and ROX-Filer
shows .desktop icon files and allows you to execute them directly. Nautilus
treats them like any other configuration file. I guess it would be relatively
difficult to trick a Nautilus user into executing a script they thought was an
image.)

The article claims that reading from the disk is extremely slow and so this
results in a significant speed up. It is pretty quick to parse the images
compared to reading the files off disk.

If the security considerations are relevant, you could presumably write the
operating system not to render the icon of non-installed software tools.

~~~
willvarfar
> I think the Linux practice of having a separately identified file provide
> the icon is relatively rare

Windows File Manager primarily uses the extension, e.g. all DOC files are
shown with the MS Word logo.

More recently, they have generated thumbnails for a lot of media files too.

~~~
squiggleblaz
I was referring specifically to the limited case of executables. As I
mentioned, executables in Windows have a resource that is the icon. There's
probably no real security issues in having a photo show up with a Word
document icon.

Windows File Manager (which was used till Windows 3.11 and Windows NT 3.51)
doesn't show generated thumbnails, although Windows Explorer does.

------
nonbirithm
I have to say that I'm infatuated by 32x32 pixel art icons. There's something
about the art style that screams early-2000s. I especially like the ones
produced by someone named Masatoshi Ueji. He even drew BeOS icons.

[http://pcdesktops.emuunlim.com/pictures/icons/beos_5.gif](http://pcdesktops.emuunlim.com/pictures/icons/beos_5.gif)

[https://web.archive.org/web/20070211213920/http://www.venus....](https://web.archive.org/web/20070211213920/http://www.venus.dti.ne.jp:80/~mueji/icons/icons.htm)

[http://pcdesktops.emuunlim.com/icons11-15.shtml](http://pcdesktops.emuunlim.com/icons11-15.shtml)

It's a bit of a shame HiDPI is a thing so people use much higher resolution
icons now, but you could just upscale them I guess.

------
aduitsis
I think the greatest image format of all time for icons was
[https://en.wikipedia.org/wiki/X_PixMap](https://en.wikipedia.org/wiki/X_PixMap)
/s. It all went downhill afterwards.

Imagine my surprise when I cat'ed an .xpm file in 1996 and saw something that
looked like C.

------
bArray
Shameless plug for a similar endeavor, but for low end embedded devices that
need small vector icons and font: [https://github.com/danielbarry/pt-
draw/tree/feature/basic-ic...](https://github.com/danielbarry/pt-
draw/tree/feature/basic-icons)

It's currently a work in progress, but the intention is to develop this for
drawing simple vector graphics to the Pine Time:
[https://wiki.pine64.org/index.php/PineTime](https://wiki.pine64.org/index.php/PineTime)

------
ktpsns
Time for fun project stories: I once wrote a Java GUI program. That was 2007,
Swing was still a thing, and "rich" frontend were still very basic (since
there were no really good HTML engines for Swing/AWT).

So one day, I thought I would replace all bitmap icons in my application with
SVG icons, because hell yes, vector, it must be better. And other projects did
it alreay at that time, such as KDE/Gnome which used
[https://wiki.gnome.org/action/show/Projects/LibRsvg](https://wiki.gnome.org/action/show/Projects/LibRsvg)

So I added a Java library for rendering SVG to bitmaps. It brought several
Megabytes of JAR dependencies. These libraries were much bigger then my whole
application.

Conclusion? The whole program was much slower then before. Rendering time was
really a thing. And this was not about thousands of icons or so, just a pretty
standard GUI application with a few (less then ten) icons at a time.

Lession learned: Processing vector images to bitmap takes more time then just
displaying bitmap. Especially on old slow computers.

------
erikpukinskis
Side note: I’m kind of shocked that they dropped the isomorphic style for the
icons. That was a truly... iconic! aspect of the BeOS visual language. And
quite modern in my opinion!

The pixel-perfectness of the UI was also iconic. If it were me, I’d go back to
isomorphic and go deep on a rigorous system-wide grid. You can still do vector
icons but be meticulous about the grid.

~~~
aidenn0
I think you mean isometric (that's where the X, Y, and Z axes all have the
same scale, and are 120 degrees apart).

Fun fact: pixel art is usually not-quite isometric because they use a vertical
line and then lines that have a slope of 2:1 which is about 7 degrees larger
distance between the X and Y axis[1].

1:
[https://en.wikipedia.org/wiki/Isometric_video_game_graphics#...](https://en.wikipedia.org/wiki/Isometric_video_game_graphics#/media/File:Perspective_dimetrique_cube_gris.svg)

~~~
erikpukinskis
That is a fun fact! That means both isomorphic AND isometric are the wrong
word for what BeOS did.... they did military/oblique coordinates?

It’s special because you get very smooth, very sharp diagonals.

I think they also compressed the vertical scale though so the proportions look
a little more natural.

------
ChrisMarshallNY
This makes perfect sense, and it seems that the article spends most of its
time "selling" vector.

As a designer, I ALWAYS start with vector (usually an Illustrator file).

No need to sell it to me, but I'd gently suggest using existing vector
formats, like SVG.

That said, most operating systems don't support the use case described. It
would be nice if they did. That may be coming, but for now, we are stuck with
BitMap. I'm glad that I don't need to use the damn .ico files anymore for Web
sites.

------
ksec
The Headline needs to add (2016).

I think some of the criticism to bitmap may no longer be valid. Such as Disk
Space, Access Time with Modern SSD, along with added computation required for
Vector Drawing instead of Bitmap. That is also assuming vector can do low
level detail hinting as good as bitmap.

------
jancsika
The devil in me wants to gather up a rag-tag group of designers and get them
to start doing incremental improvements to the Haiku icon set. Then sit back
and watch as the veteran devs begin discouraging that rapid development
because it causes too many system-wide file writes.

~~~
waddlesplash
How would it cause too many system-wide file writes...?

Most files on Haiku don't use custom icons, they just use the icon associated
with the mimetype. Application binaries the primary consumer of the icons-in-
attributes feature.

------
fireattack
Random thought, but why the vector versions of both the folder and cassette
reader use perspective projection while the bitmap versions are using
parallel/isometric projection?

It doesn't look good for this kind of icons IMO.

------
6d6b73
How does vector graphic compare to bitmap when it comes to cpu usage? It
wouldn't make sense to save few bytes in memory only to spend more cpu
resources later.

~~~
mfcl
I don't think it matters since the result would probably be cached in RAM
anyway.

------
cfv
How would this compare to brotli-ed svg?

~~~
ekimekim
In general, compression works much better the more data it has to work with.
When you're talking about one or two KiB files, the overheads are going to eat
into a lot of your gains. It's definitely still worthwhile, but I can see how
a custom packed binary format could easily outperform a compressed text format
at these sizes.

