You can now use WebPDecBuffer, WebPBitstreamFeatures and WebPDecoderOptions
to have better control over the decoding process (and the speed/quality tradeoff).
WebPDecoderOptions allow to:
- turn fancy upsampler on/off
- turn in-loop filter on/off
- perform on-the-fly cropping
- perform on the-fly rescale
(and more to come. Not all features are implemented yet).
On-the-fly cropping and scaling allow to save quite some memory
(as the decoding operation will now scale with the output's size, not
the input's one). It saves some CPU too (since for instance,
in-loop filtering is partially turned off where it doesn't matter,
and some YUV->RGB conversion operations are ommitted too).
The scaler uses summed area, so is mainly meant to be used for
downscaling (like: for generating thumbnails or previews).
Incremental decoding works with these new options.
More doc to come soon.
dwebp is now using the new decoding interface, with the new flags:
-nofancy
-nofilter
-crop top left width height
-scale width height
Change-Id: I08baf2fa291941686f4ef70a9cc2e4137874e85e
Wrap WebPEncode???* to provide an interface similar to decode.
As only WebPGetEncoderVersion is wrapped directly from encode.h avoid
including it in the swig file to reduce %ignore's.
This change also removes unnecessary incremental decoding related enums.
Change-Id: I0b5424026aa6ae012c6a29ad2f2301c2681ca301
Currently only supports a subset of decode functions and likely only
works fully for java.
For java bindings:
The generated java source can be compiled and the class files added to
libwebp.jar.
The generated jni source can be compiled to, e.g., libwebp_jni.so, which
can then be loaded via System.loadLibrary("webp_jni").
Change-Id: I8225933cbaf85c9cfa4b78c2e5f167cee8b62408
This is a (minor) bitstream change: if the 'color_space' bit is set to '1'
(which is normally an undefined/invalid behaviour), we add extra data at the
end of partition #0 (so-called 'extensions')
Namely, we add the size of the extension data as 3 bytes (little-endian),
followed by a set of bits telling which extensions we're incorporating.
The data then _preceeds_ this trailing tags.
This is all experimental, and you'll need to have
'#define WEBP_EXPERIMENTAL_FEATURES' in webp/types.h to enable this code
(at your own risk! :))
Still, this hack produces almost-valid WebP file for decoders that don't
check this color_space bit. In particular, previous 'dwebp' (and for instance
Chrome) will recognize this files and decode them, but without the alpha
of course. Other decoder will just see random extra stuff at the end of
partition #0.
To experiment with the alpha-channel, you need to compile on Unix platform
and use PNGs for input/output.
If 'alpha.png' is a source with alpha channel, then you can try (on Unix):
cwebp alpha.png -o alpha.webp
dwebp alpha.webp -o test.png
cwebp now has a '-noalpha' flag to ignore any alpha information from the
source, if present.
More hacking and experimenting welcome!
Change-Id: I3c7b1fd8411c9e7a9f77690e898479ad85c52f3e
Makes things lighter at the expense of requiring the user
to be up-to-date for autotools.
patch by Jan Engelhardt (jengelh at medozas dot de)
Change-Id: Icfcab2d899828a213d9fade0dab350dacd0c070a
converts PNG & JPEG to WebP
This is an experimental early version, with lot of room
of later optimizations in both speed and quality.
Compile with the usual `./configure && make`
Command line example is examples/cwebp
Usage:
cwebp [options] -q quality input.png -o output.webp
where 'quality' is between 0 (poor) to 100 (very good).
Typical value is around 80.
More encoding options with 'cwebp -longhelp'
Change-Id: I577a94f6f622a0c44bdfa9daf1086ace89d45539
