Post a Comment On: cbloom rants

"NewDCT" is a test compressor that I did for RAD. Let's run it through our chart treatment. For reference, I'll also include plain old JPEG huff , default settings, no PAQ. log rmse :
[Image] scielab ms-ssim :
[Image] A few notes : Note that the blue "jpeg" line is two different jpegs - the top one is jpegflatnosub , optimized for rmse, the bottom one is regular jpeg, optimized for perceptual metric. In contrast "newdct" is the same in both runs, which is semi-perceptual. The first graph is mainly a demonstration of something terrible that people in literature and all over the net do all the time - they take standard jpeg_huff , which is designed for perceptual quality, and show PSNR/RMSE numbers for it. Obviously JPEG looks really bad when you do that and you say "it's easy to beat" , but you are wrong. It's terrible. Stop it. In fact in the second graph we see that JPEG's perceptual optimization is so good that even shitty old jpeg_huff is competitive with my newdct above 1.0 bpp . Clearly I still have things to learn from JPEG. I have no idea what's up with jpeg_paq going off the cliff for small file sizes; it becomes worse than jpeg_ari. Must be a problem in the PAQ jpeg stuff, or maybe an inherent weaknesss in PAQ on very small files that don't give it enough data to learn on. Note that the three JPEG back ends always give us 3 horiztonal points - they make the same output, only the file sizes are different. (I'm talking about the bottom chart, in the top chart there are two different jpegs and they make different output, as noted previously). Below 0.50 bpp JPEG does in fact have a problem. All more modern coders will have a straighter R/D line than JPEG does, it starts to slope down very fast. But, images generally look so bad down there that it's rather irrelevant. I noted before that the "money zone" is -1 to 1 in log bpp, that's where images look pretty good and you're getting a good value per bit.