state of lossless
Pascal Massimino
James Zern
On Apr 11, 2:01 am, Pascal Massimino <pascal.massim...@gmail.com>
wrote:
>
> you might have noticed a big transfer and refresh of files from
> 'experimental' to the 'master' branch
> in the repository
> close
> to getting usable now and comments about the format, code, etc. is much
> welcome.
wants to try the update without having to build from source.
[1] http://code.google.com/p/webp/downloads/list
Szabolcs Péter
Nigel Tao
> * a reviewable PDF for the lossless spec is available
> as doc/webp-lossless-format-spec.pdf from experimental branch.
> Please, have a look and comment! There's surely some details to iron out
> regarding robustness of the syntax, ease-of-implementation, corner cases,
> etc.
Some notes from a quick skim:
The ARGB values are straight alpha (like PNG), not pre-multiplied
alpha, right? I'm guessing so, but I don't see that in the spec.
Section 4, "Colors are looked up by indexing them by (0x1e35a7bd * color)"
Do you need to specify endianness for how to convert an ARGB to a uint32?
Section 6, "<lz77-coded image> ::= (<rgba-pixel> etc"
s/rgba/argb/, right?
Jyrki Alakuijala
> On 11 April 2012 19:01, Pascal Massimino <pascal.m...@gmail.com> wrote:
>> * a reviewable PDF for the lossless spec is available
>> as doc/webp-lossless-format-spec.pdf from experimental branch.
>> Please, have a look and comment! There's surely some details to iron out
>> regarding robustness of the syntax, ease-of-implementation, corner cases,
>> etc.
>
> Some notes from a quick skim:
>
> The ARGB values are straight alpha (like PNG), not pre-multiplied
> alpha, right? I'm guessing so, but I don't see that in the spec.
>
> Section 4, "Colors are looked up by indexing them by (0x1e35a7bd * color)"
> Do you need to specify endianness for how to convert an ARGB to a uint32?
no, the argb has been defined as a uint32 in the spec, defining that b
is the lowest 8 bits
>
> Section 6, "<lz77-coded image> ::= (<rgba-pixel> etc"
> s/rgba/argb/, right?
fixing this
> --
> You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
> To post to this group, send email to webp-d...@webmproject.org.
> To unsubscribe from this group, send email to webp-discuss...@webmproject.org.
> For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/?hl=en.
>
Jyrki Alakuijala
> Hmmm, the new code sometimes creates bigger files than the old (even with -c
> 100), sometimes smaller, though mostly about the same size...
On our 1000 image test corpus, the new code compresses about 50x
faster than the encoder in the first release in November, but produces
about 3 % more bytes. Most of the compression degradation is because
of algorithmic speedups (possibly around 2 %), and the rest because of
simplification of the format (1 %).
Encoding at -c 0 seems now faster than libpng and produces still 25 %
less bytes, and -c 95 (default) is a bit faster than pngout and gives
similarly 25 % less bytes.
Another piece of good news is that the decoding speed is also a bit
faster than libpng now, although so far I have only benchmarked the
experimental decoder (the production decoder should end up having
similar or better performance).
Jyrki Alakuijala
>> * a reviewable PDF for the lossless spec is available
>> as doc/webp-lossless-format-spec.pdf from experimental branch.
>> Please, have a look and comment! There's surely some details to iron out
>> regarding robustness of the syntax, ease-of-implementation, corner cases,
>> etc.
>
> Some notes from a quick skim:
>
> The ARGB values are straight alpha (like PNG), not pre-multiplied
> alpha, right? I'm guessing so, but I don't see that in the spec.
I thought very carefully about this in the beginning of the work,
guided by earlier experiments in trying out byte-size-optimize storing
of pre-multiplied argb images in png.
I decided to not to specifically support the pre-multiplied mode. The
reasons for it are relatively complicated to explain, but I am giving
it a try.
1. Doing the pre-multiplication immediately after loading the image is
a cheap operation.
2. Alpha is typically not strongly correlated with R,G,B, which means
that pre-multiplication mixes independent entropy sources, increasing
the total entropy in R,G, and B channels.
3. Alpha-premultiplication throws away information so it should be, in
theory, good for compression, but one would need to have delicate
compensation algorithms to decorrelate the A from the R,G,B signals
for best compression. Such mechanisms would increase the complexity of
the format.
4. Pre-processing of the R,G,B channels can be done in a way that
throws away same amount of information than pre-multiplication, but
does no increase the entropy of R,G,B channels.
5. We need to keep a non-premultiplicative mode for other uses and for
compatibility with existing formats (for example png).
6. Having a bit to indicate premultiplication would complicate the
format, and decoder and encoder implementations.
The second statement of the abstract-section states the following, but
this message is not confirmed in the actual text.
"The lossless format stores and restores the pixel values exactly,
including the color values for zero alpha pixels."
> Section 4, "Colors are looked up by indexing them by (0x1e35a7bd * color)"
> Do you need to specify endianness for how to convert an ARGB to a uint32?
>
> Section 6, "<lz77-coded image> ::= (<rgba-pixel> etc"
> s/rgba/argb/, right?
>
Frédéric Kayser - CryoPNG
> 4. Pre-processing of the R,G,B channels can be done in a way that
> throws away same amount of information than pre-multiplication, but
> does no increase the entropy of R,G,B channels.
> including the color values for zero alpha pixels."
I'm the author of the hack called "CryoPNG" a tool intended to clean
the RGB components of completely transparent pixels in PNG files.
The PNG specs stated:
"If a region is completely transparent, don't zero out the underlying
color pixels in order to improve compression unless you've notified
the user in some way."
Well, I did worse since CryoPNG actually zeroes out the output of the
line filters, that means completely transparent pixel can end up with
non zero RGB components (the value of the reverse transformation of
the filter indeed) those will be zeroed once filtered, thus the
deflate engine receives more zeros, this slightly improves compression
of RGBA PNG images.
Now the funny thing is that at least some CryoPNG optimized PNG files
end up producing smaller webpll files:
https://extrememoderate.wordpress.com/2011/11/21/webp-gallery-oddities/
My question is:
What would be your stance if I wrote a tool that does the same but
specifically tuned for webpll files?