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
Replace usage of _WIN32 in examples as this does not guarantee the
presence of wincodec.h.
mingw-w64 notably includes wincodec.h, though other releases do not.
Under cygwin the following can be used for a WIC enabled binary:
./configure --target=i686-pc-mingw32 CC=i686-w64-mingw32-gcc.exe
Change-Id: Ica6a714c3356a8eaf88486a1c3f5aa6adde394c0
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
going down to strict -ansi c89 is quite overkill (no 'inline',
and /* */-style comments).
But with these fixes, the code compiles with the stringent flags:
-Wextra -Wold-style-definition -Wmissing-prototypes
-Wmissing-declarations and -Wdeclaration-after-statement
Change-Id: I36222f8f505bcba3d9d1309ad98b5ccb04ec17e3
WebPGetDecoderVersion() and WebPGetEncoderVersion()
will not return 0.1.2 encoded as 0x000102
dwebp and cwebp also have a new "-version" flag
Change-Id: I4fb4b5a8fc4e53681a386ff4b74fffb639fa237a
