The goal here is to compare various different image formats, starting with a source format like png or jpg and encoding to webp/j2k/etc.
Tracked Metrics
- Visual quality comparison (algorithmicially quantifyable and anecdotal via UI)
- File size
In it's current form, it's not a good example for evaluating a particular codec's compression performance. But it will give you an idea of what sort of performance you will see given the fixed, arbitrary quality setting for each codec/optimizer from your image sample. This may be helpful if you are trying to tune you image compression quality settings.
Any later revisions to this project will attempt to reduce the number of metrics being compared and more precisely control source image quality, so the resulting data will be more meaningful.
https://limitless-sands-3072.herokuapp.com/
Anyone conducting image compression experiments that wants to compare compression results given a fixed quality scheme. The code here is not super but easy to hack on.
The script will iterate over any number of source images and re-encode each image to all target formats. The resulting images will be analyzed for the difference in both byte size and visual similarity, from source to target. All results can be reviewed via a simple node server/app. For brower compatibility, all images are display in png format in the browser.
- format: webp
- format: jpeg2000
- optimizer: mozjpeg
- optimizer: pngquant2
- imagemagick cli: brew install imagemagick
- mozjpeg cli (cjpeg): brew install mozjpeg
- pngquant2 cli: brew install pngquant
- dssim cli: https://github.com/pornel/dssim
- Install the above CLI dependencies
- npm install
- dump some images into the
public/source_images
directory - run
node index.js
(Wait ... for a long time) - view results
node server.js
> localhost:4000
Modify config/config.js
to adjust compression settings & re-run
- Note: running
node index.js
willrm
all previous results.
It will use a lot. Be prepared.
All data is stored in memory then dumped into a json file. Then the json is loaded by the server. If you are conducing an experiment on a bunch of images, you'll probably need to modify the code to use a database of some kind.
There is none. This is a dumb script. If this were a more proper thing it would have
- a database
- worker queue of some kind
- probably use s3 as storage
It will run on Heroku if you can compile the slug into less than 300MB.
I have run tests on 10k images and the resulting disk space was in the hundreds of gigabytes.
That said, you could mogrify all source images before running index.js
with something like mogrify -resize 1024x1024 *.png
for instance which will help to keep disk usage down dramatically if you have source images which are thousands of pixels wide/high. And obviously, a very small example data set could be hosted. Otherwise, you need something with a lot of disk space.
j2k quality (anecdotal)
- 45: starts to loose sharpness in vector like bitmaps, but still has negative compression savings
- 37: insanve artifacts in a few images, terrible
- 41: goldilocks zone
Jason Ormand https://github.com/okor | https://twitter.com/okor