
500 Byte Images: The Haiku Vector Icon Format - luu
http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html
======
mcphage
> [Vector format] means that you only need one file per icon; it doesn’t
> matter how many sizes you want to render icons at.

That's not really true, even with vectors it's good to have different images
for different sizes, that add details (for larger sizes) or remove details and
increase component sizes (for smaller sizes), so the icons look good at
different sizes. You can see in the tape recorder icon the author shows: at
larger sizes, it looks much better than the bitmap images, but at smaller
sizes the bitmapped icons look better; the vector icons become a mush of
unclear elements. The bitmap shows pieces as proportionally larger than they
should be, so the visual elements that you consider important still show
clearly.

~~~
astrieanna
There is a feature of HVIF, called level of detail, that lets you vary what
shapes appear according to the display size. You can find it in the Icon-o-
Matic documentation. Ctrl-F for "LOD" in [https://www.haiku-
os.org/docs/userguide/en/applications/icon...](https://www.haiku-
os.org/docs/userguide/en/applications/icon-o-matic.html)

~~~
artursapek
So like media queries, in CSS? That's neat.

~~~
tzm
example:
[https://twitter.com/tzmartin/status/688950091063771137](https://twitter.com/tzmartin/status/688950091063771137)

~~~
mcphage
That's pretty cool!

------
gue5t
If you ever look into the memory consumption of modern applications and
filetypes, you'll probably both throw up and have a heart attack. Very few
people are interested in tuning the constant factors in the efficiency of
their software, even when the benefits of doing so can be really impressive as
demonstrated here.

~~~
fla
But with so much memory available on modern systems, the benefits of
optimizing makes les and less sense.

It is often not worth the effort.

~~~
Spivak
"Systems have so much memory, it doesn't matter if I increase memory usage for
simplicity or maintainability."

Now look at your stack and count how many developers could have uttered this
phrase when designing each module, subsystem, library, protocol, service,
daemon, file type, interface, or plug-in that's part of it.

We should count ourselves lucky that hardware engineers have afforded us the
ability to make such trades but we shouldn't take it for granted.

~~~
fla
In this case I think the tradeoff is not worthy. We're not in the 80s anymore
and its ok for a desktop to load an app icon with an additional file access.
Even more if its a well known vector format.

Imagine what would have happened if HTML had been a non human-readable binary
format just to spare a few bytes.

Some optimizations are counter productive.

~~~
userbinator
_Imagine what would have happened if HTML had been a non human-readable binary
format just to spare a few bytes._

If you want to "just spare a few bytes", you could do the same to HTML and
keep it text-based. Comparing something like XML and JSON shows that "human-
readable" formats can vary significantly in complexity alone.

Besides, I think we could all do with fewer layers of abstraction in our
lives. As a reverse-engineer I know once remarked, "Everything is human
readable if you have a hex editor."

~~~
paulryanrogers
XML is more extensible than JSON. So the latter if a trade off, not an
optimization. Perhaps comparing with binary XML would be better.

------
userbinator
For anyone interested in compact vector graphics, SWF (Macromedia/Adobe Flash)
has a shape format which is also similarly efficient and might be even
smaller, since it doesn't restrict things like coordinates and colour indices
to multiples of bytes --- fields are bit-aligned.

SVG is ridiculously bloated in comparison. Even PostScript and PDF are more
efficient.

~~~
donatj
SVG is a strange combination of really bloated and not easily human readable.
Try to make sense of shape data sometime. I'd expected a XML list of points
but it's nothing that clear, it's a string of letters and numbers as an
attribute of a tag. It may very well be readable if you learn the language but
it's certainly not self describing as I would have expected from an XML
format.

~~~
userbinator
_I 'd expected a XML list of points but it's nothing that clear, it's a string
of letters and numbers as an attribute of a tag_

It's like they actually noticed how much more bloat would result from making
each point an element, so instead they just decided to dump what is
essentially bastardised PDF/PostScript path data into an attribute. The
"language" also doesn't match PDF exactly, despite using a similar style of
short 1-letter commands.

Compare:

[https://www.w3.org/TR/SVG/paths.html](https://www.w3.org/TR/SVG/paths.html)

[http://www.websupergoo.com/helppdfnet/source/4-examples/17-a...](http://www.websupergoo.com/helppdfnet/source/4-examples/17-advancedgraphics.htm)

------
imaginenore
The article is wrong. The very first image is 375 bytes, not 1024:

[https://www.haiku-os.org/docs/userguide/images/apps-
images/i...](https://www.haiku-os.org/docs/userguide/images/apps-images/i-o-m-
terminal-bitmap32.png)

And I was able to losslessly reduce it to 298 bytes with PNGOUT.

The smaller image is 257 bytes, and I reduced it to 186.

~~~
prashnts
The article talks about raw bitmaps, though, while PNG is a bitmap compressed
with deflate.

Since rendering a bitmap is straightforward, I imagine it would be preferred
here for performance (I am just guessing here).

~~~
imaginenore
Isn't HVIF compressed SVG? They basically substituted the verbose tags with
binary, which is a form of compression.

~~~
prashnts
You're right of course. However, I'd not call it compression of SVG. HVIF
seems to have defined a simplified encoding (probably inspired by SVG)?

[Edit]: HVIF is rendered in a single pass (except in a few cases), while SVGs
(and most vector format) render each element individually.

------
grenoire
There seem to be a few constraints regarding the object count (255 with just
one byte). Even though you could say that most icons won't be complex enough
to need that, it's an unnecessary limitation that saves two or three bytes at
best.

Other than that, pretty incredible work. Vector image compression at encoding
level is definitely interesting. I alsolove posts in which binary formats are
explained, so...

~~~
wongarsu
Variable length integers could have easily increased the object count limit
with only a very small increase in size. VLQ[1] would have been one good
choice, but various other schemes would have allowed the same size as a one-
byte encoding with up to about 250 objects while still allowing larger
numbers.

But of course that increases encoder and decoder complexity. For icons, a 255
style/path limit seems reasonable and keeps the code simple.

[1]: [https://en.wikipedia.org/wiki/Variable-
length_quantity](https://en.wikipedia.org/wiki/Variable-length_quantity)

~~~
Mindless2112
PrefixVarint [1] is usually a better choice than VLQ. It's faster to decode
and requires the same number of bits.

[1]
[https://news.ycombinator.com/item?id=11263378](https://news.ycombinator.com/item?id=11263378)

------
amptorn
Get it down to 280 bytes and you can fit one in a tweet:
[https://github.com/ferno/base65536](https://github.com/ferno/base65536)

------
mschwaig
I don't understand the application of this to filesystems. To me it sounds
like it the usual way to have file icons is a simple mapping from a file type
to an icon file, and in this solution that icon gets put into the metadata of
the file instead of it's own file, so it's not a property of the file type
anymore, but of the individual file. This couples the FS implementation to the
GUI right? Isn't that horrible? If you want to change the Icon for one file
type now you have to walk the whole file system and touch the metadata of
every file. Also if you change the extension of the file, you have to change
the icon in the metadata as well.

Edit: I would just teach the GUI to cache the icon folder in RAM.

~~~
donatj
I imagine it's similar to MacOS where you can edit the icon of any file type
and its stored in a resource fork.

------
d33
Haiku! Hadn't heard about this project for long time. What's their status
right now? How active is the development?

~~~
mtmail
They still post monthly summaries, seems active [https://www.haiku-
os.org/blog/pulkomandy/2016-07-28_haiku_mo...](https://www.haiku-
os.org/blog/pulkomandy/2016-07-28_haiku_monthly_activity_report_july_2016)

~~~
jeff_petersen
I hope it someday gets to the point where I can use it as a daily driver. I
think it's really cool, and as long as it runs a web browser and allows me to
SSH into another machine for anything that requires another OS I'd be happy.
It would be a lot of fun to play around with.

~~~
feiss
Yeah, I loved BeOS in the old times, and I'd really love Haiku would get more
mainstream and productive for daily use. Its combination of speed, lightness,
simplicity and cohesion is something to envy from other OSs. I love it.

I wonder what's the reason of its slow acceptance..

------
rcthompson
It's stated that the goal is to fit file icons into inodes to avoid additional
disk accesses. How much of an issue is this on an SSD instead of a hard disk?

~~~
ldjb
I'm curious as to how you'd update the icon for a file type. Would you have to
update the inode of every single file of that type? That can't be too
efficient.

I'm sure there are ways of getting around the problem, but having lots of
duplicate data (even if each icon is very small) isn't generally a good idea
(but perhaps this is an exception).

~~~
rcthompson
Yeah, I'm a bit confused about what this is for. Any icons common to an entire
file type should be cached in RAM already, so I the only thing I can think of
would be file-specific icons. But I expect most of those would be thumbnail
images, which would not be amenable to a concise vector representation.

------
davidgerard
That's amazing!

How's it compare to a minimised SVG, gzipped, in practical terms? I see
projects elsewhere just blithely using SVG or SVGZ. (or, in horrifying cases,
multiple sizes for hundreds or thousands of icons.) Perhaps this is a thing
that would be suitable to wider use if it can get good lib support.

~~~
prashnts
SVGs generated from popular vector editing softwares can get very complex with
cascading style overrides, transformations etc. Even though SVGz would reduce
the file size, parsing the SVG tree and rendering will still be unoptimized.

Optimization tools do exist [1] to simplify the tree but they can do only so
much good[0]. I think this format, built with optimality might be a solution.

[0]: Anecdotal. I once had to edit ~20 icons. The client had provided SVGs
because they'd somehow lost the original AI files. When I imported them in
Sketch 3, the nesting, masks, and transforms applied were absolutely
horrifying! I had to optimize the icons using [1], which did remove the masks
and transforms, but in the end I had to manually edit SVG's XML source to fix
nestings. _sigh_.

[1]: [https://github.com/svg/svgo](https://github.com/svg/svgo)

~~~
davidgerard
I know _exactly_ what you mean. Approximately everyone uses Inkscape in
practice, but I too have had occasion to go into gvim and edit the Inkscape
SVG by hand. I will say that it really helps to know what's going on, but
_having_ to is less than ideal.

("approximately everyone" to the point where Wikimedia occasionally considers
just using Inkscape-as-a-service as the SVG renderer instead of rsvg, for best
quirk-compatibility.)

~~~
Ezhik
I used Inkscape recently, and found it quite a nightmare to use, even if its
UI reminded me of Corel Draw quite a bit.

That's what I get for spending like a decade primarily using Photoshop, I
suppose.

~~~
davidgerard
It is impossible to use Inkscape without running through at least some of the
tutorials. Once you have a good conceptual understanding and have found some
of the stupid bits that make no sense (what, you expected "Object Properties
..." to contain, ooh I dunno, _properties_ of the _object_?) it's entirely
suited to doing proper work. But no, its interface is very bad on
discoverability.

------
cooper12
This seems to be the source she is referring to:
[https://github.com/tqh/haiku-
efi/tree/master/src/libs/icon/f...](https://github.com/tqh/haiku-
efi/tree/master/src/libs/icon/flat_icon), specifically the FlatIconFormat
class. Some of the most interesting deconstructions and experiments have come
out of The Recurse Center, great learning experiences and blog posts by these
students. I found the concept of the format interesting in how it meets the
goals of being modern (a vector format) while staying slim for disk reads
(optimizing the format specifically for icons). Lastly the usability aspect is
tackled by creating an icon editor specifically for the format. In the
creator's blog post, he notes that creators might not be able to take full
advantage of the format because they might not know how the it works, but I
think it's fine since the format constrains the palette anyway.

------
WhitneyLand
Leah, please consider this:
[http://contrastrebellion.com](http://contrastrebellion.com)

~~~
JohnStrange
I'd rather like to see a movement against websites that force users to
vertically scroll down page after page to read three paragraphs of text.

~~~
eyelidlessness
That's interesting. Because clearly separating parts of content too far
presents a usability challenge of its own, but failing to separate them enough
presents a similar set of usability challenges.

I personally tend toward the "users do scroll, it's okay to make long pages"
school of thought. But certain extreme cases are extremely unpleasant to use.
That said, I don't consider this one case so extreme, because it at least does
not take over my ability to scroll at the pace I expect.

~~~
derefr
I think the problem here might be that, if you're skimming the text of these
"slides" and not looking at the illustrations, you can actually read faster
than it's _possible_ to scroll on most computers, and thus "stall your
[visual] pipeline." Normally, with scrolling, I can still read _while_ I'm
scrolling. In this case, I have to read-THEN-scroll-THEN-read-THEN-scroll,
etc.

------
twelvechairs
Isn't one of the reasons why bitmaps are used that icons should actually vary
from a standard vector image when shown at very small sizes to remain clear
and readable?

This icon library shows some good examples.

[http://mezzoblue.com/icons/chalkwork/](http://mezzoblue.com/icons/chalkwork/)

------
Esau
Given the processing power of modern computers, I have always been surprised
that operating systems haven't moved to vectors for all user interface
elements. You would think this would be desired for resolution independence,
if nothing else.

------
anthk
The problem is that the shadows on smallest sizes are not so clear and the
icons are harder to see.

------
watersb
Macintosh PICT was just a bytestream of Toolbox draw calls. I think Windows
EMF was too.

------
agumonkey
The innate proportion-consistency of pixel art still fascinates me.

