New WebP tools released!

[Pascal Massimino]

Dear all, 

as of a few hours ago we released to the open source repository the biggest update to WebP to date. 

We completely rewrote the encoder to focus on the quality for still images. We also added many

ad-hoc adjustments that make WebP really fit to image compression while still being bitstream-compliant

with VP8.

Let us know what you think after you've downloaded the binaries or compiled from source.

This release is supported on Windows, Mac and Unix.

Also noteworthy, we introduced a Windows Imaging Component build to facilitate support for WebP

on the Windows ecosystem.

For more information, please point your browser to the main WebP page:

 

   http://code.google.com/speed/webp/index.html

Also, don't forget to take a glance at the new gallery of great images!

skal, on behalf of the WebP team

[Jan Engelhardt]

On Feb 23, 4:06 am, Pascal Massimino <pascal.massim...@gmail.com>
wrote:

> Dear all,
>
> as of a few hours ago we released to the open source repository the biggest

> update to WebP <http://code.google.com/speed/webp/> to date.

> Let us know what you think after you've

> downloaded<http://code.google.com/speed/webp/download.html>
>  the binaries or
> compiled<http://www.webmproject.org/code/#libwebp_webp_image_library>
> from source.

I think this needs attention. Right now, it invokes undefined behavior
somewhere in cwebp and subsequently is killed with SIGBUS, which I
will investigate in shortly too. I already identified more undefined
behavior in dwebp and submitted a patch.

Since there is no SCM yet, I started one at git://dev.medozas.de/libwebp
based upon the 0.1 tarball. There is also my branch of patches.

[Pascal Massimino]

Hi,

On Fri, Mar 25, 2011 at 9:14 AM, Jan Engelhardt <jen...@medozas.de> wrote:

On Feb 23, 4:06 am, Pascal Massimino <pascal.massim...@gmail.com>
wrote:

> Dear all,
>
> as of a few hours ago we released to the open source repository the biggest

> update to WebP <http://code.google.com/speed/webp/> to date.

> Let us know what you think after you've

> downloaded<http://code.google.com/speed/webp/download.html>
>  the binaries or
> compiled<http://www.webmproject.org/code/#libwebp_webp_image_library>
> from source.

I think this needs attention. Right now, it invokes undefined behavior
somewhere in cwebp and subsequently is killed with SIGBUS, which I
will investigate in shortly too. I already identified more undefined
behavior in dwebp and submitted a patch.

please make sure you sync your investigation to the latest HEAD revision.

There's been a lot of fixes sync the initial v0.1-1.

Actually, i'm about to package a v0.1-2 now that the incremental decoding

feature is in (and soon to be incorporated in Chrome).

Thanks for investigating!

Since there is no SCM yet, I started one at git://dev.medozas.de/libwebp
based upon the 0.1 tarball. There is also my branch of patches.

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

[Pascal Massimino]

Hi Jan,

On Fri, Mar 25, 2011 at 12:31 PM, Jan Engelhardt <jen...@medozas.de> wrote:

On Friday 2011-03-25 20:24, Pascal Massimino wrote:
>>>Dear all,
>>>
>>>as of a few hours ago we released to the open source repository
>>>the biggest update to WebP <http://code.google.com/speed/webp/> to

>>>date. Let us know what you think after you've downloaded the
>>>binaries or compiled from source.

>>
>>I think this needs attention. Right now, it invokes undefined behavior
>>somewhere in cwebp and subsequently is killed with SIGBUS, which I
>>will investigate in shortly too. I already identified more undefined
>>behavior in dwebp and submitted a patch.
>
>please make sure you sync your investigation to the latest HEAD
>revision.

There was (and is) no SCM offered as of yet, so referring me to any
HEAD seems strange. Unless you mean my copy, but that I am already
using.

ooh, no i realize that the main page on code.google.com is lacking a clear reference to the

main code repository:

   http://www.webmproject.org/code/#webp-repositories

which is hosted near the companion WebM project.

Will fix the landing page ( http://code.google.com/speed/webp/)

>There's been a lot of fixes sync the initial v0.1-1.
>Actually, i'm about to package a v0.1-2 now that the incremental
>decoding feature is in (and soon to be incorporated in Chrome).

Please avoid such strange numbering (make it v0.1.2 if you have to),
the number after the dash is the release (of the very _same_
version) and usually reserved for distributions.
(libwebp exists as libwebp-0.1-2.1.x86_64.rpm already in openSUSE,
and libwebp-0.1-2-2.1 would really throw this off.)

ah. I had the debian package numbering in mind:

http://qa.debian.org/developer.php?login=j...@debian.org (still pending review)

as well as the gentoo one:  http://packages.gentoo.org/package/media-libs/libwebp

They're all based on the 0.1 packages we released here: http://code.google.com/speed/webp/download.html

and which are bound to be updated.

Didn't know about the openSUSE one.

I'm not sure how to harmonize the numbering here.

Any suggestion?

[Mikołaj Zalewski]

As I understand, we (as the "upstream") should only care what's
before the dash and use dots, while the distribution package
maintainers will add will add dashes with the version of the package
build (e.g., we release 0.1.2, they will build 0.1.2-1, then they
build 0.1.2-2 if they find a typo in package description, then 0.1.2-3
if they decide it to build it with different ./configure options etc).
Different distributions may end up with a different package version
(after the dash), but that shouldn't be a problem.
Note that as the first version was 0.1 (as the "-1" is the Debian
package version), this means that 0.1.2 will be skipping one point,
but we could consider the incremental decoding to be big enough to
justify this.

Mikołaj

[Pascal Massimino]

Hi,

2011/3/25 Mikołaj Zalewski <miko...@google.com>

indeed. Actually, it's my bad: i wrote 0.1-2 in my original message when

i should have written 0.1.2. The typo was of importance, as Jan explained.

I'm going to upload a tentative libwebp-0.1.2-rc1.tgz cut from HEAD, so you

can give it a try.

Thanks for the precisions.

[Pascal Massimino]

Hi,

2011/3/25 Pascal Massimino <pascal.m...@gmail.com>

It's now uploaded as:

    http://webp.googlecode.com/files/libwebp-0.1.2-rc1.tgz

Will do more testing and then build the libs for MacOS/linux/Windows/etc.

[Jan Engelhardt]

On Friday 2011-03-25 20:24, Pascal Massimino wrote:
>>>Dear all,
>>>
>>>as of a few hours ago we released to the open source repository
>>>the biggest update to WebP <http://code.google.com/speed/webp/> to

>>>date. Let us know what you think after you've downloaded the
>>>binaries or compiled from source.

>>
>>I think this needs attention. Right now, it invokes undefined behavior
>>somewhere in cwebp and subsequently is killed with SIGBUS, which I
>>will investigate in shortly too. I already identified more undefined
>>behavior in dwebp and submitted a patch.
>
>please make sure you sync your investigation to the latest HEAD
>revision.

There was (and is) no SCM offered as of yet, so referring me to any

HEAD seems strange. Unless you mean my copy, but that I am already
using.

>There's been a lot of fixes sync the initial v0.1-1.

>Actually, i'm about to package a v0.1-2 now that the incremental
>decoding feature is in (and soon to be incorporated in Chrome).

Please avoid such strange numbering (make it v0.1.2 if you have to),

[Jan Engelhardt]

On Friday 2011-03-25 22:40, Pascal Massimino wrote:
>
>>>There's been a lot of fixes sync the initial v0.1-1. Actually, i'm
>>>about to package a v0.1-2 now that the incremental decoding
>>>feature is in (and soon to be incorporated in Chrome).
>>
>>Please avoid such strange numbering (make it v0.1.2 if you have
>>to), the number after the dash is the release (of the very _same_
>>version) and usually reserved for distributions. (libwebp exists as
>>libwebp-0.1-2.1.x86_64.rpm already in openSUSE, and
>>libwebp-0.1-2-2.1 would really throw this off.)
>
>ah. I had the debian package numbering in mind:
>http://qa.debian.org/developer.php?login=j...@debian.org (still
>pending review) as well as the gentoo one:

Debian follows the same principle - the number after the dash is
reserved for changes to the distro package itself, that is, the
.dsc/.diff.gz (deb), or .spec/.diff (rpm), _for when the tarball
remains unchanged_.

> http://packages.gentoo.org/package/media-libs/libwebp They're all
>based on the 0.1 packages we released
>here: http://code.google.com/speed/webp/download.html and which are
>bound to be updated. Didn't know about the openSUSE one.
>
>I'm not sure how to harmonize the numbering here.

As a provider of the original tarball, you should not be concerned
with "releases"(in the sense of distro packaging), but only
"versions"(in the sense of distro packaging).

Outside distro packaging, the term "release"(in the sense of tarball
package), when it is used, is equal to "(distro) version".

If you create a new tarball, you are effectively bumping the version.

The most recent version of libwebp is 0.1, as found on the
code.google download page -- and this has been correct so far.

Possible numbers for a new release are 0.1.1, or 0.2, or 1.0
if you desire -- that is up to you.