Vector Art Optimization Challenge #2

Challenge #1 was fun. In the name of belated continuity, some may be interested reviving the concept.

This time the aim of the challenge is to compress the svg's file size as much as possible, while still maintaining the svg format which can be rendered live.

Here is the image to start with:


Svg source here.

Original image is 1099356 bytes. How small is the smallest?

Do you want to keep the arcs / number of objects? Or is only the rendering relevant?

Only the rendering is relevant.

The original image is built up from ellipse objects so "arcs" may not be the best wording here. 46 sectors should be present in the image with a checker pattern of 40 rings (if I counted them right).

Next time, we should use a forum where attachments are allowed...

https://framadrive.org/s/Imlqlbj4RNniH94/download (download)

11383 byte

Could still be made smaller if all transforms were removed.

Nice one!

Using a custom dasharray isa very effective way to deal with the pattern.

For further optimizing, you can try https://jakearchibald.github.io/svgomg/.
And/or maybe we should set in the rules the minimal number of decimals used etc. Can get close to crashing with a low value.

Moini wrote:Next time, we should use a forum where attachments are allowed...

I've taken a look at the administrative settings for this forum, and as far as I can tell attachments are allowed.

@Xav: thanks for checking - unfortunately, then, something else must be wrong. The second tab ('Attachments') that is usually there when using 'Full Editor & Preview' is not available for me here (while it is for the Help section) ... :-/

Lazur, did you try the further optimization?

I made 7 variations beforehand announcing this topic, but didn't want to ruin the fun -actually my best bet was drawn with custom dasharray as well.
Made some mistakes with it, will probably redraw it soon. (That file was so heavily compressed it crashed several time while zooming in...)
Still, could think of 4 or 5 more ways of drawing it.

My very first variant was this:

-15817 bytes-
(with maximum precision and decumals set as default, saved as inkscape svg)

later remix after using that previously linked online svg optimizing tool:

-4177 bytes-

You can still remove " paint-order="fill markers stroke" " and the 'overflow: hidden' as well as the style attribute from the last one (currently, doesn't load due to OCAL having issues).

999 bytes.
There are a few spaces that could be removed to make the file smaller, but on the other side the file is a bit off because of rounding errors (see the empty hole at the center) so I guess a precise version will still be under 1K



<svg width="1000" height="1000" xmlns:xlink="http://www.w3.org/1999/xlink">
<style>
circle {
stroke:#ddd;
fill:transparent
}
circle.a {
fill:#444;
}
</style>
<defs>
<g id="c">
<circle cx="500" cy="500" r="400" stroke-width="30" stroke-dasharray="54.6, 54.6" />
<circle cx="500" cy="500" r="372" stroke-width="27.68" stroke-dasharray="50.78, 50.78" stroke-dashoffset="50.78" />
</g>
<g id="d">
<use href="#c"/>
<use href="#c" transform="translate (70, 70) scale(0.86)" />
</g>
<g id="e">
<use href="#d"/>
<use href="#d" transform="translate (130, 130) scale(0.74)" />
</g>
<g id="f">
<use href="#e"/>
<use href="#e" transform="translate (226.2, 226.2) scale(0.548)" />
</g>
<g id="g">
<use href="#f"/>
<use href="#f" transform="translate (350, 350) scale(0.3)" />
</g>
</defs>
<circle class="a" cx="500" cy="500" r="415" fill="#444444" />
<use href="#g"/>
<use href="#e" transform="translate (455, 455) scale(0.09)" />
</svg>

910 bytes (if you remove all unnecessary spaces)
now center is fine

loads fine in chrome/firefox. Not in inkscape.

draw a circle of background color.
draw the outer circle with dotted stroke and no fill
size of a dot = 2*pi*radius / 46 = 0.1366 radius
I choose a radius of 500 and a stroke width of 50 [*] so the real radius is 500 - 50/2 = 475 (because the stroke is 50% inside 50% outside)
so dot size = 0.1366 * 475 = 64.88
draw the next circle with a ratio of 0.9
so the wanted radius is 500*0.9 = 450
I don't remember why but for this one I chose to use a stroke width of 450 and an adapted radius of 225
(stroke width of 45 and adapted radius of 452.5 should be fine too)
so for this one dot size would be 0.1366 * 225 = 30.73


you could repeat the process 20 times but it is better to clone those 2 rings.
we clone it a first time with a ratio of 0.81 (0.9*0.9) and add it to the original so
we got a 4 rings pattern.
we clone the clone with a ratio of 0.81*0.81 and we add the clone
we got a 8 rings pattern
we clone again
we got a 16 rings pattern
we clone again
we got a 32 rings pattern

we draw the 32 rings pattern
plus
we draw the clone of clone (=8 circles pattern)
=
we drew 40 rings


The choice of a width of 500 and a stroke width of 50 is more a matter of luck than anything else.
To do it well one should have start from the center and goes to the outer circles.
so if we set the width of inner circle to 1 and chose a 10% increment,
then next circle width would be 1.1,
next 1.21
next 1.331
next 1.4641
and total width of circles will be sum 1 + 1.1 + 1.21 + 1.331 + 1.4641 + ...




<svg width="1000" height="1000" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
<style>
circle{stroke:#ddd;fill:none}
circle.n{fill:#777}
</style>
<defs>
<g id="c">
<circle cx="500" cy="500" r="500" class="n" />
<circle cx="500" cy="500" r="475" stroke-width="50" stroke-dasharray="64.88,64.88"/>
<circle cx="500" cy="500" r="225" stroke-width="450" stroke-dasharray="30.73,30.73" stroke-dashoffset="30.73"/>
</g>
<g id="d"><use href="#c"/><use href="#c" transform="translate(95,95)scale(0.81)"/></g>
<g id="e"><use href="#d"/><use href="#d" transform="translate(171.95,171.95)scale(0.6561)"/></g>
<g id="f"><use href="#e"/><use href="#e" transform="translate(284.77,284.77)scale(0.4305)"/></g>
<g id="g"><use href="#f"/><use href="#f" transform="translate(407.35,407.35)scale(0.1853)"/></g>
</defs>
<use href="#g"/>
<use href="#e" transform="translate(480,480) scale(0.04)"/>
</svg>

As far as I understand, only a few board here allow attachments. I can never remember which ones they are. But I remember some that aren't are this one, WIP and Completed Works.

To be honest the permissions system in phpBB is overly complex. There's no single "allow attachments" permission for the forum, but rather it's done by a combination of role, user group and forum. I've double-checked and "registered users" should be able to add attachments, so I can't really tell why it's not working.

As a second attempt, however, I've now used an option in phpBB to copy the permissions from another forum (Help With Using Inkscape), so let's see if that makes a difference. I'm loath to poke things too much, however, as although I have admin rights to the forum, I don't have access to the host (i.e. there's no way I can create or restore backups as insurance against anything going horribly wrong).

Xav, it worked! I've got that second tab now

attachment work for me now

v1nce wrote:910 bytes
test.svg

Great!
Guess we have a winner already.

My original intention was to see a variety of different constructions to "skin the cat".
Will post some obscure variations soon.

I gave it a try in 1946 bytes (entirely done in inkscape, saved as optimized svg), then hand-removed some useless stuff to 1556 bytes

Basically I started from one of the ellipse parts in the original file and worked from clone, rotate (or resize), group with original, clone group, redo

Welcome aboard!

Great to see you here as well -and an impressive result.

by the way, v1nce's solution can further be improved that way to 804bytes:

<offtopic>Hi Marc!</offtopic>

Mc- wrote:by the way, v1nce's solution can further be improved that way to 804bytes:

Well done Sir.

There are still some unnecessary spaces remaining. And some numbers could be written as .x rather than 0.x.
The new code would be less than 800 bytes (797 if I count it right)



Using a width of 10 instead of 1000 should save a few bytes more, but Chrome does not allow to zoom that much so it's practically unusable.

Argh. Omitting space between transform items is not valid.

The individual transform definitions are separated by whitespace and/or a comma

that's 5 more bytes. We're no more under 800 bytes

But i guess it's safe to assume the version="1.1" attribute could be discarded. That's 14 bytes less. 797 +5 -14 = 788 bytes.
If the svg is inlined we could remove the namespaces declarations too.

The original image that sparkled the idea was 1099356 bytes and *very* sloppy. That's 0,07%.
svg source