Re: [Libjpeg-turbo-devel] Further research regarding the effectiveness of SmartScale

[Siarhei S. <sia...@gm...>]

On Tue, 15 Jan 2013 13:12:01 +0200
Siarhei Siamashka <sia...@gm...> wrote:

> 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?

Sorry, got Jyrki's e-mail wrong, now adding to CC for real.

-- 
Best regards,
Siarhei Siamashka