The output was always 99dB because the lossless pipeline is not
modifying the 'picture'. Changing that is not that simple because
near_lossless impacts both VP8ApplyNearLossless() and
ApplyPredictFilter(); the latter cannot be applied as is to the input
and thus the final modified 'picture' cannot be easily retrieved
without decoding the encoded bitstream. Hence ReadWebP() is called in
cwebp.c on the encoded bitstream kept in memory to get the correct
distortion.
However -get_psnr returns a different distortion than get_disto for
lossy encoding configurations because cwebp loads the source as YUV
while get_disto directly reads it as RGB without conversion loss.
Change-Id: I5c32cf8f89eb137973dc7eebda747682d921b8e2
Fix another pessimization found by the pingo image compressor.
Refactoring is necessary to make LZ77 computation
common to cache or no-cache analysis.
Slower by 1.7x instead of 2x
Change-Id: I396701ea6e88543dbfe9471eb552877f6c8ce1e3
qmin / qmax are now using the pad[] spot at the end of the struct,
and we don't need to bump the ABI major number.
Change-Id: I41adcaf1600b29a5a05c9fe380bfd977cf425124
keep the minimum, but recommend the latest so we don't need to update
this in the future.
BUG=webp:463
Change-Id: I0615039323d3c77684c6be2e890514f6973cf535
remove EMSCRIPTEN_GENERATE_BITCODE_STATIC_LIBRARIES, this option is only
supported with the deprecated fastcomp backend; the wasm version will
begin to throw an error if it's used. 1.39.12 already fails to build when
using this option.
+ fix a typo
BUG=webp:463
Change-Id: I7175df4d5b2b6cb6aaf20eb41063c09c03b9b69a
this was not giving a good alpha value, making the method 5/6 a little
blurrier than method 4 (!).
Change-Id: I69b9890dea21499c1af1753e87d9f7adf8b433de
This is particularly useful for multi-pass search (but not only),
to prevent the search from going over or below a reasonable threshold.
E.g.: 'cwebp -qrange 50 80 ...' will prevent any unreasonable degradation.
new cwebp option: -qrange min max
Change-Id: I59f394533535fc20b6996bc0895f4301476d5eff
when building a dll based libwebp include the dsp private symbols that
WebPUnmultiplyARGB requires
Change-Id: I7cf7da0b20d6cf6740219c8562380926a0abd93c
(cherry picked from commit cf047e8347)
when building a dll based libwebp include the dsp private symbols that
WebPUnmultiplyARGB requires
Change-Id: I7cf7da0b20d6cf6740219c8562380926a0abd93c
this is defined to 0 by dsp.h if it wasn't defined previously, since:
47178dbd extras: add WebPUnmultiplyARGB() convenience function
Change-Id: If4dd48360a95b2786410670cff5ac655227fb6dd
PredictorSub0_SSE2 doesn't use 'upper' (neither does
VP8LPredictorsSub_C[0]); just pass NULL when dealing with trailing
pixels to avoid undefined behavior when offsetting a NULL pointer
BUG=chromium:1026858,oss-fuzz:19430
Change-Id: I08be8899ed2e34f26aaee34defe68dbd0fe216d3
some toolchains may implement vcreate_u64 as an assignment to a vector
causing a type mismatch:
invalid conversion between vector type 'uint64x1_t' (vector of 1
'uint64_t' value) and integer type 'unsigned int' of different size
const uint64x1_t LKJI____ = vcreate_u64(L | (K << 8) | (J << 16) | (I << 24));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: I5c7b0076ad66d4b3fcdcb7ee9f59bbaa6f19b783
The workaround for GCC ARM must not be applied when another toolchain
(like MSVC) is used for the build.
Change-Id: I11ec4558902063ccb085d3f435e24b3a60739dd5
'upper' could be NULL and it would be increased.
But that is for predictor zero that does not use 'upper'.
Change-Id: Icd4ae6792cc55ea021b4f828c3dbdb5f03e120d8
add some missing dependencies and convert utility libraries to
static only libraries to avoid creating unnecessary shared object
libraries which may fail to link due to missing symbols.
Change-Id: Iaa91a3d97fa5af6ada4b2a851cc7fc2879d871da
Since people seem to write "2 ^ X" hoping that it means "1 << X", clang
recently added a warning for this pattern.
It incorrectly fires on this file. To suppress it, restructure the code
to be less clever. (Alternatively we could use "xor" instead of "^" or
write "0x2" instead of "2" but both seem worse.)
No intended behavior change.
Bug: chromium:995200
Change-Id: I64744345be5f5a8cd1f4aaeaf0982da239b378a7
