... both of which are actually broken. The .NET one just fails myseriously on me. The webp.zip one has some broken Endian stuff, and even if you fix that the BMP input & output is broken. So.. I ripped it out and relaced it with the cblib BMP in/out, and it seems to work.
(I didn't want to use the webp converter in ffmpeg because I've seen past evidence that ffmpeg doesn't do the color conversion and resampling right, and I wanted to use the Google-provided app to make sure that any bad quality was due only to them)
My build of WebP Win32 is here : webp.zip
Here are the results :
log rmse :
ms-ssim-scielab :
Now I am surprised right off the bat that the ms-ssim-scielab results are not terrible, but the rmse is not very good. I've read rumors in a few places that On2 tweaked WebP/WebM for RMSE/PSNR , so I expected different.
Looking at the RMSE curve it's clear that there is a bad color conversion going on. Either too much loss in the color convert, or bad downsample code, something like that. Any time there is a broken base color space, you will see the whole error curve is a bit flatter than it should be and offset upwards in error.
The perceptual numbers are slightly worse than jpeg-huff through the "money zone" of -1 to 1. Like all modern coders it does have a flatter tail so wins at very low bit rate.
(BTW I think JPEG's shortcoming at very low bit rate is due to its very primitive DC coding, and lack of deblocking filter, but I'm not sure).
BTW I also found this pretty nice Goldfishy WebP comparison
Also some pretty good links on JPEG that I've stumbled on in the last few days :
jpeg wizard.txt
ImpulseAdventure - JPEG Quality Comparison
ImpulseAdventure - JPEG Quality and Quantization Tables for Digital Cameras, Photoshop
ImpulseAdventure - JPEG Compression and JPEG Quality
Here's how the WebP test was done :
webp_test.bat : call dele s:\*.bmp call dele s:\*.webp Release\webp -output_dir s:\ -format webp -quality %1 r:\my_soup.bmp Release\webp -output_dir s:\ -format bmp s:\my_soup.webp namebysize s:\my_soup.bmp s:\my_soup.webp s:\webp_ .bmp call mov s:\webp_*.bmp r:\webp_test\ md r:\webp_test call dele r:\webp_test\* call webp_test 5 call webp_test 10 call webp_test 15 call webp_test 20 call webp_test 25 call webp_test 30 call webp_test 40 call webp_test 50 call webp_test 60 call webp_test 65 call webp_test 70 call webp_test 75 call webp_test 80 call webp_test 85 call webp_test 90 call webp_test 95 call webp_test 100 call mov s:\webp_*.bmp r:\webp_test\ imdiff r:\my_soup.bmp r:\webp_test -cwebp_imdiff.csv transposecsv webp_imdiff.csv webp_trans.csvBTW the webpconv app is really annoying.
1. It fails out mysteriously in lots of places and just says "error loading" or something without telling you why.
2. It takes an "output_dir" option instead of an output file name. I guess that's nice for some uses, but you need an output file name option for people who are scripting. (you can fix this of course by making your batch rename the input file to "webp_in" or something then you ran rename the output at will)
3. It's got image format loaders for like 10 different formats, but they're all semi-broken. Don't do that. Just load one standard format (BMP is good choice) and support it *well* , eg. be really compliant with variants of the bitstream, and let the user convert into that format using ImageMagick or something like that.
4. It won't write the output files if they already exist, and there's no "force overwrite" option. This one had me absolutely pulling out my hair as I kept running it with different options and the output files stayed the same. (you can fix this of course by making your batch delete the output first)
Despite all this negativity, I actually do think the WebP format might be okay if it had a good encoder.
ADDENDUM : WebP on Moses :
On "my_soup" it looked like WebP was at least close to competitive, but on Moses it really takes itself out of the running.
BTW there is a certain class of images where WebP is definitely much better than JPEG, which is semi-line-art like images, stuff with big smooth gradients and flat color chunks and such.
ReplyDeleteWhich actually is a pretty common case on the web. It's stuff that often could have just been PNG, but people are lazy so having a generic format that works for photos or digital graphics is not a bad thing.