difficult sources for Lossless mode

[GoogleCodeExporter]

What steps will reproduce the problem?

Some sources are larger than PNG (not a new issue), but also
have a hard-to-predict size when -m and -q parameters are
changed. In particular, -m 5 or -m 6 give worse results than
-m 2 or -m 3.

Steps to reproduced, as reported on the mailing list:

================

First example: 2013-11-30_142558.png. It is attached right now. It uses 12,157 
bytes.
The more smaller WebP file I succeded to generate is 12,904 bytes with this 
command: > cwebp -lossless -m 3 -q 100 2013-11-30_142558.png
File:      2013-11-30_142558.png
Dimension: 1280 x 212
Output:    12904 bytes
Lossless-ARGB compressed size: 12904 bytes
  * Lossless features used: PREDICTION CROSS-COLOR-TRANSFORM SUBTRACT-GREEN
  * Precision Bits: histogram=4 transform=5 cache=8

I tried also several other commands (see 2013-11-30_142558.txt in Tests.tar.xz) 
but all these commands produce bigger/equally-sized files.

Another example with 2013-10-24_034946.png. Also attached. This PNG uses 25,977 
bytes.
But the smallest WebP file I succeded to generate is 27,034 bytes wit this 
command: > cwebp -lossless -q 100 2013-10-24_034946.png
File:      2013-10-24_034946.png
Dimension: 1280 x 214
Output:    27034 bytes
Lossless-ARGB compressed size: 27034 bytes
  * Lossless features used: PREDICTION CROSS-COLOR-TRANSFORM SUBTRACT-GREEN
  * Precision Bits: histogram=4 transform=4 cache=8

There’s logs of all my tries in 2013-10-24_034946.txt in Tests.tar.xz.
I don’t know what should I think. -m X does have an influence, but using -m 6 
is not always the better solution. :(
-pass X seems to do nothing. -q 100 has helped to save 2 bytes in 
2013-11-30_142558.png and 266 bytes in 2013-10-24_034946.png.
However, -m 6 -q 100 can use more than -m 6, as 2013-11-30_142558.txt prooves 
it.

============

Original issue reported on code.google.com by pascal.m...@gmail.com on 3 Dec 2013 at 4:39

Attachments:

• 2013-10-24_034946.png
• 2013-11-30_142558.png

[GoogleCodeExporter]

Archiving Jyrki's comment on the mailing list here:

===================================
PNG encodes entropy changes for a stream of bytes, which are a scan line. When 
there is variation of entropy on a horizontal lines, PNGs entropy model is more 
efficient than that of WebP, which uses the same entropy for a square area. For 
example, a PNG with a line of two randomly pixels A and B, followed with a line 
of two varying pixels C and D would have a representation:

(entropy code 1) A B A B B A B A B ... A B  (entropy code 2) C D C C C D C D D 
... D C

In WebP, such an image would be coded with:

(entropy code 1) A B A B (entropy code 2)  B A B A  ...
(entropy code 1) C D C C (entropy code 2)  C D C D  ...

PNG model is more efficient for tight horizontal lines. About 1 % of images, 
and particularly wide images with long horizontal lines, can be coded more 
efficiently as PNGs.

Original comment by pascal.m...@gmail.com on 22 Aug 2014 at 3:43

[GoogleCodeExporter]

As mentioned in the bug, following are the scenarios that make some (about 1%) 
of the optimized PNG images hard sources for WebP lossless:

1.) PNG is excellent for images where entropy changes by rows of image.
2.) For images with very high aspect ratio (W/H). PNG adds one byte per scan 
row line to represent the filter mode, where as WebP lossless have multiple 
transforms that apply on 8x8 or 16x16 segments of the image. The compressed 
data to represent the multiple transforms could be (sometimes) 5-10% of the 
WebP lossless bitstream.
3.) The PNG input for some cases could be coming from pngout that are already 
optimized globally (for choices like palette order assignment, multiple passes 
to the get the shortest distance in creating backward references via zlib 
option). WebP lossless compression is done based on some default settings. It 
could be possible to generate globally optimum WebP lossless by combination of 
various compression knobs tuning.

Original comment by vikaas.a...@gmail.com on 23 Sep 2014 at 10:03

[GoogleCodeExporter]

Original comment by vikaas.a...@gmail.com on 23 Sep 2014 at 10:04

• Changed state: Done