we map the input file into memory, even in the non-stdin case.
This is less efficient than letting the png/jpeg/... decoding libraries
use fread()'s, but more general.
Change-Id: I4501cb9a1daf69593eb8e3326c115cd8cbdf92fd
-> read is a bit slower (memory allocation and such) than reading directly from disk.
-> we're not yet ready to accept stdin as input (-- -) because we still need to guess
the file type with GetImageType(). And since we can't rewind on stdin, this will need
a bit more work before being able to read from stdin.
Change-Id: I6491fac4b07d28d1854518325ead88669656ddbf
This is to infer the needed conversion to YUV(A) or RGB(A).
This is useful to avoid some conversion steps between ARGB and YUVA.
For instance, if the input file is a JPEG, we decode to RGB and
convert to YUV right away, without the intermediate step to ARGB.
The only caveat is that cropping/scaling might give slightly different result,
because of YUV420 downsampling. Therefore, we omit this feature
at cwebp level, when -crop or -rescale is used.
Change-Id: I5a3abe5108982f2a4570e841e3d9baffc73f5bee
rather than symlink the webm/vpx terms, use the same header as libvpx to
reference in-tree files
based on the discussion in:
https://codereview.chromium.org/12771026/
Change-Id: Ia3067ecddefaa7ee01550136e00f7b3f086d4af4
