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].
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 :)
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".
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.
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."
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.
> 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.
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.
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.
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
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.
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 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 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.
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.
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).
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.
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.
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.
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.
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