search

cxt / webp

Automatically exported from code.google.com/p/webp
0 stars 0 forks source link

Red and blue colors change during jpg converstion to webp #232

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
cwebp input_jpg.jpg -o output_webp.webp

What is the expected output? What do you see instead?
The red and blue letters experience color change during conversion to webp.

What version of the product are you using? On what operating system?
libwebp v0.4.1  Also present in most recent Master Branch.

MIPS: fix functions to use generic BPS istead of hardcoded value …
djpimg authored 4 days ago
Change-Id: I2d68abef886eff7f8df230f155b758dccd7d04fd

Windows 7

Please provide any additional information below.
May be related to Issue 218: Image's colors change when converted to WebP

Original issue reported on code.google.com by zin...@gmail.com on 8 Dec 2014 at 10:31

Attachments:

GoogleCodeExporter commented 9 years ago 
This could be due to the color profile or the fact that the input is 444. Can 
you try '-pre 4' to see if it helps in this case?

Original comment by jz...@google.com on 9 Dec 2014 at 12:11

GoogleCodeExporter commented 9 years ago 
the color change is mostly due to the yuv444->yuv420 downsampling.
Using the '-pre 4' option helps in that case, by using a 'smart' converter for 
yuv420,
albeit a slower one than the default.

Attached, the result from 'cwebp input_jpg.jpg -pre 4 -o output_pre4_webp.webp'
(using code at HEAD)

Original comment by pascal.m...@gmail.com on 9 Dec 2014 at 6:56

Attachments:

GoogleCodeExporter commented 9 years ago 
Thank you for looking at this. The -pre 4 option seems to correct the red 
letters, however the blue letters now show shades of red that do not exist in 
the input.

Original comment by zin...@gmail.com on 9 Jan 2015 at 9:03

Attachments:

GoogleCodeExporter commented 9 years ago 
the color bleeding seems to be an "expected" chroma compression artifact, that 
one starts to see when quality setting is getting lower. Chroma plane is 
quantized more aggressively than luma one, and in this particular case (thin 
blue features over a white background) its shows more prominently than usual.

I tried raising the quality to -q 90, and the effect is less pronounced (while 
the file size is still reasonable).
See example attached.

Original comment by pascal.m...@gmail.com on 15 Jan 2015 at 12:13

Attachments:

GoogleCodeExporter commented 9 years ago 
That looks great, pascal.  Do you know when -pre 4 is going into a release? 
It's disabled in 0.4.3, because of the flag in encode.h

#define WEBP_ENCODER_ABI_VERSION 0x0202    // MAJOR(8b) + MINOR(8b)

Original comment by zin...@gmail.com on 1 Apr 2015 at 6:36

GoogleCodeExporter commented 9 years ago 
There's ongoing work to make it faster (like: 
https://gerrit.chromium.org/gerrit/74014). Right now this function is still too 
slow to be switched on by default.
But, agreed, we'll activate this function asap by removing this VERSION check, 
even if it's not made default for RGB->YUV conversion.

Original comment by pascal.m...@gmail.com on 3 Apr 2015 at 12:52

GoogleCodeExporter commented 9 years ago 
This check only exists in the 0.4.x release branches for compatibility 
purposes. 0.5.0 branched from master will expose the function, but there are 
still a few things to be done before we release that. To test this for now a 
tip of tree build will be best.

Original comment by jz...@google.com on 3 Apr 2015 at 7:11