[HN Gopher] IconVG is a compact, binary format for simple vector...
___________________________________________________________________
IconVG is a compact, binary format for simple vector graphics
Author : bpierre
Score : 103 points
Date : 2021-06-05 12:21 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| therealunreal wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jagged-chisel wrote:
| 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"
| deburo wrote:
| 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
| jepler wrote:
| 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 wrote:
| Neat!
|
| Why not do that with HTML?
| pdenton wrote:
| 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 wrote:
| There's not a single perfect format for everything, so why not?
| makapuf wrote:
| 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?
| asddubs wrote:
| I wish those size comparisons would compare it to gzipped svgs as
| well
| xyproto wrote:
| It would make sense to compare it with gzipped iconvg files,
| then.
| cosmotic wrote:
| SVG is XML so it's very verbose but is fairly compressible.
| Comparing all four would make a lot of sense.
| folmar wrote:
| 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.
| thayne wrote:
| 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 wrote:
| 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.
| thayne wrote:
| 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.
| ape4 wrote:
| 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.
| formerly_proven wrote:
| - 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
| chrisseaton wrote:
| What do you mean by 'ad-hoc encoding'? Isn't any new proposed
| encoding 'ad-hoc' until it becomes established?
| sdflhasjd wrote:
| Well, SVG is xml for example.
| verginer wrote:
| 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 wrote:
| 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
| marcodiego wrote:
| How does it compare against svgz?
| jokoon wrote:
| 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.
| ysleepy wrote:
| With both compressed using `gzip -9` the advantage is still 2x.
| Tested with the samples in the test dir.
| marcodiego wrote:
| 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.
| karim79 wrote:
| Oh nice! Coming soon to a https://kraken.io near you.
| gardaani wrote:
| 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.
| maxxk wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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...
| r1ch wrote:
| 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.
| contriban wrote:
| 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.
| cosmotic wrote:
| 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.
| r1ch wrote:
| 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.
| cosmotic wrote:
| 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.
| folmar wrote:
| The large services with user content care a lot. If you are
| Reddit instead of Facebook performance starts to matter.
| r1ch wrote:
| 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: htt
| ps://www.redditstatic.com/gold/awards/icon/Illuminati_512
| ...
| [deleted]
| CyberRabbi wrote:
| > cowbell.png is 18555 bytes (256 x 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 wrote:
| 917 cowbell.ivg.gz 1017 cowbell.ivg 2217
| cowbell.svg.gz 4506 cowbell.svg 18223
| cowbell.png.gz 18555 cowbell.png
| Symbiote wrote:
| Also Brotli compression: 1863 cowbell.svg.br
| mikewarot wrote:
| 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 wrote:
| 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.
| mikewarot wrote:
| 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.
| TazeTSchnitzel wrote:
| There is plenty of poorly-documented code from 20 years
| ago. Bear in mind that IconVG is not a commercial product.
| grishka wrote:
| 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.
| TazeTSchnitzel wrote:
| 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?
| raphlinus wrote:
| There's a proposal for a new version that has a much richer
| imaging model: https://github.com/googlefonts/colr-gradients-
| spec
| formerly_proven wrote:
| 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).
___________________________________________________________________
(page generated 2021-06-05 23:01 UTC)