IconVG is a compact, binary format for simple vector graphics

[maxxk]

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

[tqh]

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/

[felixr]

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

[AshamedCaptain]

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

[therealunreal]

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/

[chgibb]

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.

[mimixco]

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.

[formerly_proven]

- 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

[nigeltao]

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

[chrisseaton]

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

[RazrFalcon]

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

[CyberRabbi]

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

[folmar]

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

[watersb]

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.

[gardaani]

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.

[deburo]

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

[ysleepy]

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

[marcodiego]

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.

[nigeltao]

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

[mikewarot]

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.

[TazeTSchnitzel]

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.

[grishka]

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.

[asddubs]

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

[xyproto]

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

[pdenton]

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

[ajconway]

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

[thayne]

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.

[HelloNurse]

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.

[ape4]

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.

[TazeTSchnitzel]

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?

[formerly_proven]

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

[raphlinus]

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

[verginer]

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?

[cjohansson]

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

[r1ch]

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.

[cosmotic]

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.

[contriban]

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.

[marcodiego]

How does it compare against svgz?

[jokoon]

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.

[jepler]

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.

[jokoon]

Neat!

Why not do that with HTML?