webP and webM support in LiveCode

Alejandro Tejada capellan2000 at gmail.com
Fri Aug 25 15:12:20 EDT 2017

Hi Monte,

on Thu Aug 24 2017, Monte Goulding wrote:
> webM would require a reasonable size refactor to players because
> we would need to wrap a custom player around the library and then
> decide which player to use depending on the movie file.
> webP on the other hand looks like it could be added without any
> refactoring, however, as you can imagine there is a _lot_ of work
> in adding an image format. It could be that such work is justified
> by the HTML5 project to help with file size. Failing that and given
> there’s a workaround of not using the format I imagine it would take
> a business services contract or an open source contribution to get
> it done. Then there’s considerations like whether adding the library
> to the engine is comparable in size to any savings one might make
> using the format. Not an issue for a browser that displays many websites
> but for us it would make the project a net loss.

I agree about webM, but savings in storage space provided
by webP are the best reason for implementing this image
compression format within LiveCode engine.

WebP format is between 60 and 40% smaller than JPG
images providing much better image quality.
WebP compress flat color graphics (with transparency)
much better than PNG or GIF.

This is not a guess based on visual comparisons.
Anyone could confirm these numbers, installing these
files and programs in their own computer:

0) Download these Standard Test Images
or use your own images:

1) Convert these TIFF and PNG images to
WebP (100% Quality) and (80% Quality)

Convert these TIFF and PNG images
to JPG (100% Quality) and (87% Quality)
using GIMP, ImageMagick or your favorite
image conversion software.

Notice that webP images are between
60% and 40% smaller than visually
equivalent JPG images.

2) Install ImageMagick:
and compare original TIFF and PNG images
with compressed webP and JPG using
any or many of these algorithms that
measure the differences between images:

    absolute error count, number of different pixels (-fuzz effected)
    structural dissimilarity index
    mean color distance
    mean absolute error (normalized), average channel error distance
    mean error per pixel (normalized mean error, normalized peak error)
    mean error squared, average of the channel error squared
    normalized cross correlation
    peak absolute (normalized peak absolute)
    perceptual hash for the sRGB and HCLp colorspaces.
    peak signal to noise ratio
    root mean squared (normalized root mean squared)
    structural similarity index

For example:

magick compare -metric SSIM Peppers.tif PeppersQ100.webP result01.png

magick compare -metric PSNR Peppers.tif PeppersQ100.webP result01.png

Results are mind opening and confirm these findings:

Remember that just 10 years ago (when Internet speed
was only 56k), JPG and GIF ruled the web, Flash movies
were harmless fun, PNG was just another novelty and
SVG was a gleam in the eyes of their creators.

Today, computers are much, much powerful than
10 years ago and image compression algorithms
have advanced using this new computer power.

Could you believe that an Android tablet from 2015
(that cost me only 5 dollars) could play HD video
much, much better than an Intel Atom PC
from 2005? (that cost more than 200 dollars)

Today, WebP and WebM could be only the new kids
on the block of image formats, but in a near future
wavelet and fractal compression could rule, offering
better quality and smaller file size than current
image formats.

Please, before ruling out completely the opportunity
to include a modern compressed image format
like webP, read the FAQ and API:



More information about the Use-livecode mailing list