Hacker News new | ask | show | jobs
by maxxk 1837 days ago
It would be interesting to compare this representation with Haiku vector image format described in post [0] and discussed a couple of times here [1, 2].

0: 500 Byte Images: The Haiku Vector Icon Format http://blog.leahhanson.us/post/recursecenter2016/haiku_icons...

1: https://news.ycombinator.com/item?id=12420763

2: https://news.ycombinator.com/item?id=22373422

3 comments

IIRC HVIF is designed to render in one pass as well targeting to be both small and fast. It also use non-standard floating point, to be even more compact. And has more than two level of details. So guessing HVIF is a lot better except for tooling outside Haiku :)

Here is an article from 2006 about HVIF: https://www.haiku-os.org/news/2006-11-06_icon_facts/

Not a comparison to HVIF, but some reasoning on why not just use HVIF:

  The Haiku Vector Icon Format is pretty close. Unfortunately, I didn't
  find a written specification, only a single C implementation, tightly
  coupled, as far as I could tell, to the Haiku operating system. Also,
  https://www.haiku-os.org/articles/2009-09-14_why_haiku_vector_icons_are_so_small
  says that "you wouldn't really want to use HVIF to store generic
  vector graphics".
From 2016 post introducing IconVG https://groups.google.com/g/golang-nuts/c/LciLeI5p8k8/m/vSid...:
HVIF requires some pre-tuning on the source icons so it may never be an apples to apples comparison.

In any way I find the author's statement that, because HVIF claims "you wouldn't really want to use HVIF to store generic vector graphics", then HVIF should not be considered as an alternative.

Precisely HVIF excels as a "compact, binary format for simple vector graphics" and that is exactly what they mean when they say that it should not be used for generic vector graphics. So I could claim this is just reinventing the wheel...