Hello www-svg,
Attached are the images I used to make a size comparison during the
face to face.
First I found a bitonal image on the web, Saito_bwStucki.png. Looking
at how this was encoded there was some inefficiency:
so I recompressed it, reducing the filesize. This optimised PNG image
was used as the basis for subsequent comparisons.
I also saved this image as a bitonal TIFF using CCITT Group 4 fax
compression, as used by CGM for inline bitonal images.
I then created a data uri with base64 encoding, and put this in a text
file.
Lastly I put that into an SVG file, vieewed it to be sure the entire
image was present, and then noted the size of that (also the size when
compressed).
Compression was done with gzip -9. Here are the sizes:
original png 15,228 Saito_bwStucki.png
optimised png 12,438 Saito_bwStucki-iv.png
g4 compressed TIFF 20,258 Saito_bwStucki-iv-fax4.tif
base64 data uri 16,613 iv-base64.txt
data uri compressed 12,623 iv-base64.txt.gz
svg with data uri 16,759 svg-iv-base64.svg
svg compressed 12,746 svg-iv-base64.svgz
The variation in size between the optimised PNG and the compressed SVG
with inline, base-64-encoded image in a data url was 12,438 to 12,746
or in other words 2.4% larger in this example.
This contrasts strongly with the comparison in the Henderson -
Wiedenbrück paper, which showed an explosion from 65k (PNG) to 1,732k
(SVG), 990k (svg compressed) or an increase of 1,523% !!
It appears that the Henderson - Wiedenbrück paper was using SVG export
from a very early version of Adobe Illustrator (this was in 2003-4)
which included a lot of reound-tripping information including a
base-64 encoded PDF file in the SVG metadata element. This severely
skewed the comparison.
Both this quick experiment and the original study use a single
example. A proper study should be conducted using a much larger corpus
of raster data.
--
Best regards,
Chris mailto:chris@w3.org
