IconVG is a compact, binary format for simple vector graphics | Hacker News Reader

IconVG is a compact, binary format for simple vector graphics

github.com

144 pointsbpierre57 comments

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

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

I found this a few days ago when I was researching SVG in Flutter. After the initial "why not SVG?" reaction, this is not that bad! As the README says, It is a format for efficient presentation, not an authoring format. You're supposed to author in SVG etc and then export to IVG.

However, SVG Native [1] seems to be very similar, and it's also a subset of SVG, and non-binary.

1: https://svgwg.org/specs/svg-native/

SVG in Flutter still leaves a lot to be desired. We've ended up building a subset of SVG that can be composed using const code that fills some of the missing gaps in packages like flutter_svg.

That looked interesting until I got to this quote:

"SVG Native is a standalone file type, expected to be rendered with a dedicated-purpose renderer. Therefore, SVG Native content must not be present as part of a larger XML (or HTML) document. If it is present as part of a larger XML (or HTML) document, the content should be interpreted as SVG proper."

So in other words, no SVG native in the browser.

I would have assumed that meant it shouldn't be included inline; that referencing it via URL is fine. Do we know which they mean?

Edit- found this: "If a Web author desires to use SVG Native on the Web, the img element may be used instead"

- No color management, works in an unspecified color space (probably meant to be sRGB?)

- Only 8-bit RGB, baked in at every level of the spec

- Only two levels of detail per file

- Uses some weird encoding scheme to stuff gradients into the invalid states of pre-multiplied alpha

- Completely ad-hoc encoding

What do you mean by 'ad-hoc encoding'? Isn't any new proposed encoding 'ad-hoc' until it becomes established?

Well, SVG is xml for example.

> Only two levels of detail per file

There are multiple levels of detail per file. Each LoD is specified by two numbers: a lower and upper bound on the height-in-pixels that enables the subsequent drawings.

Well, it's based on SVG, which is also RGBA8888 sRGB only (effects can optionally use LinearRGB).

    > cowbell.png is 18555 bytes (256 × 256 pixels)
    > cowbell.svg is 4506 bytes
    > cowbell.ivg is 1017 bytes

They did not use a gzipped version of the svg file which would be a more fair comparison. Someone else in this thread actually compared with a gzipped version of the svg file and claimed the savings were still 2x.

I suspect the savings from using IconVG over gzipped svg would be decreased as the size of the source file increased. Though that would need verification.

If we assume the size benefits aren’t significant, I think this is really only valuable for implementing vector graphics presentation on small / embedded systems, given these leaves out a lot of svg features.

It may also be the case that existing svg renderers have suffered from code bloat and aren’t very embeddable. I suspect that a well written and small svg implementation may negate many of the reasons for IconVG’s existence.

    917 cowbell.ivg.gz
   1017 cowbell.ivg
   2217 cowbell.svg.gz
   4506 cowbell.svg
  18223 cowbell.png.gz
  18555 cowbell.png

Also Brotli compression:

  1863 cowbell.svg.br

Surprised I don't see SVGOMG mentioned yet:

https://jakearchibald.github.io/svgomg/

I play with the settings when I care about SVG size. I don't know what real developers do, but I got a skewed version of cowbell.svg down to about 937 bytes.

Google has Android Vector drawables: https://developer.android.com/guide/topics/graphics/vector-d... . I think that they are compiled to binary XML (undocumented).

It would be nice to see size and performance comparisons between IconVG, SVG native (gzipped), Haiku vector images and AVD binary format.

Nigel Tao, when he announced it and later when he posted about it on HN:

- https://groups.google.com/g/golang-nuts/c/LciLeI5p8k8 - https://news.ycombinator.com/item?id=14161688

With both compressed using `gzip -9` the advantage is still 2x. Tested with the samples in the test dir.

It must be said that an svgz can be decompressed and manipulated by any svg supporting tool, including inkscape which adds specific tags to more easily edit it later.

Considering an svg takes a very little space compared to the rest of a project, this won't make a big difference on size.

Also, an svgz can be streamed decompressed at the same time it is parsed, so it is not too much of a complexity, processor time or memory even for the cheapest cellphones.

I really wonder what is the use case for this format.

Hi. IconVG author here. Thanks for the attention.

It's still a work-in-progress and I'm actually considering some major file format changes in the coming weeks. As some of you have noticed, the docs aren't complete. I wasn't expecting to hit Hacker News today.

The primary goals are simplicity and security. The file size benefits are a bonus.

Why not .svg.gz? Well, if that (or another format) works for you, that's great. But implementing SVG needs a lot of code (the SVG spec is 400 pages long) plus dependencies like XML, JavaScript and Freetype/Harfbuzz (or equivalent) libraries. It's practically impossible to do a thorough security audit over a complete implementation.

For example, https://github.com/flutter/flutter/issues/1831 says "We don't want full SVG support. There is too much in the spec that is expensive, heavyweight, and/or duplicates what we already have in Flutter."

I get that this is yet another Domain Specific Language/Virtual Machin. Quite complex in order to optimize on the input size. As long as it doesn't become Turing complete, I'm quite happy to play along.

What I don't understand is what "relative cubeTo" does. The "documentation" doesn't help, it just points at source code, and explains nothing

https://pkg.go.dev/golang.org/x/exp/shiny/iconvg#Encoder.Rel...

I missed a decade of software development, so maybe it's just me. It seems that nobody actually documents things anymore, but rather expects you to read the source code and guess.

https://github.com/google/iconvg/blob/main/spec/iconvg-spec.... also doesn't explain what relative cubeTo does, though from the context (2D vector graphics), “relative” must mean the co-ordinates are relative to the position of the cursor (as opposed to “absolute” which is relative to some fixed origin), and “cube” probably refers to cubic interpolation.

Cubic Interpolation - someone saved a few too many characters with that name.

So, that function uses opcode "c", which is documented here in SVG

https://www.w3.org/TR/SVG/paths.html#PathDataCubicBezierComm...

Now it makes sense... but that took help from the internet and a lot of time to figure out.

Is it just me, or has actual documentation been abandoned in the last 20 years?

[Edit] I accept it's not a commercial production, but if you want to drive adoption of a proposed new thing, proper documentation would greatly help.

There is plenty of poorly-documented code from 20 years ago. Bear in mind that IconVG is not a commercial product.

It most probably corresponds to the SVG command that does the same thing. Iirc that command drops some parameters and the parser is supposed to derive them from the previous point.

I wish those size comparisons would compare it to gzipped svgs as well

It would make sense to compare it with gzipped iconvg files, then.

SVG is XML so it's very verbose but is fairly compressible. Comparing all four would make a lot of sense.

I would see LZO or similar becoming more mainstream for in-transit compression - it's still quite good for low-entropy data like XML, but the speed is blazingly fast.

I'm all for good compression but tbh it's starting to get ridiculous.

HTML/CSS/JS: prefer brotli, then gzip, then identity (no compression), using the Accept-Encoding header.

Pictures: convert them all to AVIF and WEBP. Keep JPEG around as well for backward compatibility

Other bitmap/non-scalable images: I guess still use PNG unless I missed something

And now SVG, used to be compressible with brotli but soon we'll have to export it to IconVG.

What's next, changing the transport to UDP? Hah!

Oh wait...

There's not a single perfect format for everything, so why not?

I understand there might be specificities for encoding but there coukd be some efforts to share some compression. By example png use gzip, we could let the browser sort it out and let it use brotli?

This looks exciting, I hope it goes somewhere. I am a little concerned that it doesn't support text though. Tooling could probably render text as curves, which would be more consistent across platforms, but would take more space, and the text would no longer be selectable or extractable.

This is a file format for icons, the name isn't random. Typical applications that need icons are going to support text in other ways, like actual text, rather than anti-accessible bloat inside images. Moreover, text in SVG files makes sense as an editable authoring format, but depending on fonts is quite bad.

I guess that's fair. There is definitely room for a more general vector format that can replace SVG that is smaller, doesn't have scripting and external references, etc.

Text brings in many issues such as required fonts but its also something can be stored as the text itself rather than a bunch of vectors.

I wonder how it compares in terms of compression and features to Microsoft's font format extension that lets you use multiple layers with different colours, which is how Windows 10's emoji work. I remember a criticism of it was that flat design is the only possible design.

IconVG seems to at least support gradients, based on what https://github.com/google/iconvg/blob/main/spec/iconvg-spec.... says.

Incidentally, Microsoft have some other vector formats like WMF/EMF. I assume those are also more efficient than SVG?

There's a proposal for a new version that has a much richer imaging model: https://github.com/googlefonts/colr-gradients-spec

WMF/EMF is from the 90s and serializes GDI commands. I think you can hypothetically even put OpenGL commands in there, which should be indicative of how old that is (since MS dropped OpenGL like a hot potato decades ago in order to push Direct3D with the Wintel monopoly).

What is meant by the disclaimer at the end,

> This is not an official Google product, it is just code that happens to be owned by Google.

Is the code developed by an external group and google just happened to be where first prototype was developed?

No I think the author works at Google and have a couple of hours weekly or monthly to do "experiments", but the employment terms forces the ownership of the "experiments" to Google but since the projects may not align with Googles image or reputation they wish not to be officially associated with it. They own it but do not "stand behind it" officially

I think the days of developers caring about 16 KB of bandwidth savings for an image have long passed. Pages with GIFs for video content, photos saved as PNG, multiple megabytes of JS are the norm now.

Yes but icons tend to be downloaded in groups so you can x10 that value. At 160 KB it starts to look like a prime target for optimization.

Smaller files can be inlined it into the markup or other containers. If you can get it down to 1.5KB, it can fit in one ethernet frame.

I'd be quite surprised if frontend developers know the size of an Ethernet frame or TCP ICW. I'm all for these kind of optimizations, don't get me wrong, but I just don't realistically see them mattering any more.

The large services with user content care a lot. If you are Reddit instead of Facebook performance starts to matter.

Reddit is actually a great example of not caring about performance. See those tiny reward icons rendered at 12px? Here's the source image, a 512x512 1.6 MB APNG: https://www.redditstatic.com/gold/awards/icon/Illuminati_512...

I see this as largely a tooling problem.

Fireworks from the early 2000s did a great job helping with optimizing images. These days no one even thinks about it. Tools like Sketch will export SVGs but embed base64 encoded data URLs of 600dpi PNGs in them. Unobservant devs don't realize this is happening which lead to SVGs that are tens of megabytes. Sketch should know better than to do something so ridiculous without any sort of indication or warning. It's shocking how few professional design tools have working or optimal image optimization. I can drop PNGs from any app into free tools that shrink them down losslessly by 50%.

Flash did binary vector art in late 90s and we still haven't caught up to that in 2021. SVGs are still much larger than their SWF counterpart, and only in very few circumstances is any of SVGs functionality superiority relevant.

There's a big void around non-technical designers and untrained, unskilled FE devs that don't know about these problems or solutions. Is the solution yet-another binary vector format that is dead-on-arrival from google? No. But I like that there's some attention to this problem.

How does it compare against svgz?

Probably not very good, gzip is bad at compressing numerical data. It's good at compressing text, which is made of data that often repeats itself.

Compressing numerical data is done with lossy compression such as DCT.

The numbers in svg are text ultimately.

Numerical data in text is still numerical data, there is much less repetition compared to a newspaper article or blog post.

I wonder if they investigated a format for relative coordinates that used 3 bytes .. in the example ivg it would potentially save a lot of bytes, but at the cost of less exact coordinates.

Neat!

Why not do that with HTML?

Oh nice! Coming soon to a https://kraken.io near you.

Reply on news.ycombinator.com