But this got me thinking: how optimized was my JPEG encoder? I first used MSFT's .NET JPEG implementation, but I had to wonder just how good that implementation actually was. For example,
- What quantization tables does it use?
- Are its quantization tables computed on a per-image basis, or is it using the IJG reference tables?
- How are the tables being scaled, and are they being capped at 8 bits (i.e. no value larger than 256 in your quantization table) or allowed to go to 16?
- For the discrete cosine transform, is it using integer or floating point math?
- Is it using an optimized entropy encode?
So do we really need WebP? Or do we really just need to give a venerable old method some much needed love?
It is clear to me that there are various methods that can improve current JPEG performance. Using libjpeg's optimize routine, followed by a run through jpegcrush, WebP is no longer ahead. Jpegcrush itself "...abuses combinations of multiple Huffman tables and scan combinations to improve compression more than merely optimizing the Huffman tables naively," according to Dark Shikari. There are several papers about generating image specific quantization tables that minimize error for a given bitrate that look promising. So in my spare time, I'll probably investigate some of this stuff further.
4 comments:
Hi Kidjan,
Do you know if there is a jpegcrush for windows? I have tried to run the perl file on windows, using Strawberry Perl and only got some error messages.:(
@Nemo
Sorry, I don't think there is one. I've been using it on Linux.
I've wondered about that myself. Maybe JPEG would have a better chance of producing "WebP-like" results if it distributed its encoding bits in a similar manner. E.g. for http://stamga.deviantart.com/art/Beautiful-Dream-180306392 WebP spends more bits on the planets, and leaves the background noticeably blockier.
@sapphirepaw
In my own testing, WebP is not significantly better than vanilla JPEG. If we're talking JPEG with arithmetic encoding instead of huffman encoding, I'm actually finding that JPEG is comparable, if not better.
Post a Comment