Re: [Libjpeg-turbo-devel] Further research regarding the effectiveness of SmartScale
SIMD-accelerated libjpeg-compatible JPEG codec library
Brought to you by:
dcommander
From: Siarhei S. <sia...@gm...> - 2013-01-15 11:12:13
|
On Tue, 15 Jan 2013 08:47:56 +0200 Siarhei Siamashka <sia...@gm...> wrote: > On Mon, 14 Jan 2013 23:53:31 -0600 > DRC <dco...@us...> wrote: > > > Since there have been questions fielded from Fedora and others regarding > > the potential for libjpeg-turbo to support the DCT scaling and > > SmartScale features of jpeg-7 and later, I felt compelled to do some > > research into the effectiveness of these new features. The research > > revealed that DCT scaling and SmartScale do not generally accomplish > > anything that can't already be accomplished at least as well (and > > typically faster) using other means: > > > > http://www.libjpeg-turbo.org/About/SmartScale > > > > Executive summary: > > > > -- For generating lossless files, libpng was much faster (3-4x) and > > achieved similar compression ratios to jpeg-9. > > By the way, there is a paper with this lossless JPEG extension proposal > here with some compression ratio comparison tables: > http://jpegclub.org/temp/JPEG_9_Lossless_Coding.doc > > But when introducing a new and incompatible format, I think one has to > actually beat WebP and not PNG nowadays: > http://blog.chromium.org/2012/08/lossless-and-transparency-modes-in-webp.html Actually it is quite interesting that JPEG 9 filter resembles a very similar SUBTRACT_GREEN filter from WebP: https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification#transformations The only difference is that libjpeg-9 also adds CENTERVAL (0x80) to red and green, while WebP doesn't. I took 24 images from http://www.r0k.us/graphics/kodak/kodak/ for testing and tried to hack this tweak into WebP 0.2.1 with the following results. The numbers after file names are the sizes when re-encoded with 1) JPEG 9 (cjpeg –rgb1 –block 1 –arithmetic) 2) WebP 0.2.1 (cwebp -m 6 -lossless) 3) patched WebP 0.2.1 to use modified filter from JPEG 9 (1) (2) (3) kodim01.png 586755 504672 503038 kodim02.png 545688 455562 454684 kodim03.png 439830 386634 384950 kodim04.png 556177 460240 456204 kodim05.png 640895 565768 549250 kodim06.png 501072 470044 469188 kodim07.png 483621 419638 416180 kodim08.png 672957 551580 548236 kodim09.png 493393 437996 436106 kodim10.png 511781 445064 440882 kodim11.png 513196 457606 455696 kodim12.png 450743 411542 408418 kodim13.png 656770 607078 594714 kodim14.png 567437 517324 516012 kodim15.png 532043 433094 428576 kodim16.png 443120 424902 423042 kodim17.png 495714 447794 443550 kodim18.png 649763 567544 553546 kodim19.png 549028 485824 482298 kodim20.png 410066 373048 369352 kodim21.png 523610 491994 489686 kodim22.png 613626 523156 512466 kodim23.png 517928 425088 420486 kodim24.png 586314 495318 488506 Total size for JPEG 9 : 12941527 (~12.3 MiB) Total size for WebP 0.2.1 : 11358510 (~10.8 MiB) Total size for patched WebP 0.2.1 : 11245066 (~10.7 MiB) The patch itself: diff --git a/src/dsp/lossless.c b/src/dsp/lossless.c index 62a6b7b..2ea68c0 100644 --- a/src/dsp/lossless.c +++ b/src/dsp/lossless.c @@ -576,8 +576,8 @@ void VP8LSubtractGreenFromBlueAndRed(uint32_t* argb_data, int num_pixs) { for (i = 0; i < num_pixs; ++i) { const uint32_t argb = argb_data[i]; const uint32_t green = (argb >> 8) & 0xff; - const uint32_t new_r = (((argb >> 16) & 0xff) - green) & 0xff; - const uint32_t new_b = ((argb & 0xff) - green) & 0xff; + const uint32_t new_r = (((argb >> 16) & 0xff) - green + 0x80) & 0xff; + const uint32_t new_b = ((argb & 0xff) - green + 0x80) & 0xff; argb_data[i] = (argb & 0xff00ff00) | (new_r << 16) | new_b; } } @@ -595,6 +595,7 @@ static void AddGreenToBlueAndRed(const VP8LTransform* const transform, uint32_t red_blue = (argb & 0x00ff00ffu); red_blue += (green << 16) | green; red_blue &= 0x00ff00ffu; + red_blue ^= 0x00800080u; *data++ = (argb & 0xff00ff00u) | red_blue; } } Looks like WebP could get ~1% better compression if it used JPEG 9 variant of SUBTRACT_GREEN filter. And this seems to be reasonable, because with the addition of CENTERVAL, less red/blue color components are going to be overflowing and wrapping around on average. Too bad that the bitstream format seems to be already freezed for WebP. Or maybe it is still possible to get a similar effect with the other filter types in WebP? Also added Guido Vollbeding (JPEG 9) and Jyrki Alakuijala (WebP) to CC because I think they might be interested in these results or want to provide some feedback. Though I'm not sure not sure if the e-mails can pass through to the list for those who don't have a subscription. Can we retain the superior compatibility and software/hardware support in various operating systems, browsers and devices for the well established legacy JPEG format? And at the same time benefit from the improved compression ratio and/or image quality with the bleeding edge new technologies such as WebP? -- Best regards, Siarhei Siamashka |