1 space is most common in the source; this fixes some mixed cases within
lossless files, likely from clang-format
Change-Id: I504206d5bf418781d4131ee73570ecee4e0a69a1
previously failures in the call to
VP8LBackwardReferencesTraceBackwards() would be ignored which, though it
wouldn't result in a crash, would produce non-deterministic output
Change-Id: Id9890a60883c3270ec75e968506d46eea32b76d4
change CostManager to calloc to avoid frees on undefined pointer
values in CostManagerClear() should the cost_model allocation succeed,
but the cost_manager allocation fail
since:
v0.5.0-93-g3e023c17 Speed-up BackwardReferencesHashChainDistanceOnly.
Tested:
for i in `seq 1 639`; do
export MALLOC_FAIL_AT=$i
./examples/cwebp -m 6 -q 100 -lossless jpeg_file
done
Bug: webp:565
Change-Id: I376d81e6f41eb73529053e9e30c142b4b4f6b45b
initialize bw_side before calling EncoderAnalyze() & EncoderInit() which
may fail; previously this would cause a free of an invalid pointer in
VP8LBitWriterWipeOut().
since at least:
v0.6.0-120-gf8c2ac15 Multi-thread the lossless cruncher.
Tested:
for i in `seq 1 639`; do
export MALLOC_FAIL_AT=$i
./examples/cwebp -m 6 -q 100 -lossless jpeg_file
done
Bug: webp:565
Change-Id: I1c95883834b6e4b13aee890568ce3bad0f4266f0
results in code layout changes, a couple fewer instructions; some of the
smaller functions were unaffected as they were inlined, but are updated
for consistency. this mostly affects VP8Decimate(), ReconstructIntra16()
and ReconstructUV().
Change-Id: Icc2582278987a66ad1110bab683d1e0c21e6591a
A WebPPicture instance is necessary to call WebPReportProgress() which
sets WebPPicture::error_code so as well use WebPEncodingSetError() to
record errors too, instead of functions returning a WebPEncodingError.
However there must be one WebPPicture instance per thread, with error
codes merged at sync time. A mutex could simplify that but it is not
the objective of this change.
https://groups.google.com/a/webmproject.org/g/webp-discuss/c/yOiP8APubgc/m/vCTvxl6ODgAJ
Change-Id: Ia1a8f9d1199202e1c88484ce719b0180a80447ce
... when it's not available. Even if the value was discarded and
never used, some msan config were complaining about reading it
and passing it around.
Change-Id: Iab8d24676c5bb58e607a829121e36c2862da397c
- only initialize variable when needed
- perform first loop outside the for loop
- perform computation only if know we are not already worse
- not adding base_score every time
Change-Id: I2cb8231fcaec1113b5902ed61b685f0ae3c78823
replace with more inclusive terms or remove the comment entirely if the
meaning was already clear.
Bug: webp:507
Change-Id: Ica3bbf751ebf79f6668df6e6209af770248ff4ca
This reverts commit b6513fbaa8.
This change can produce files that can cause decode failures in some
versions of chrome and safari/ios/macos.
https://chromium-review.googlesource.com/c/chromium/src/+/2876279
The chrome fix will be available in M92. This change can be revisited
after it and the mac updates are more widely deployed.
Bug: b/186640109,b/188702956
Change-Id: I296b8fe88c6c48219e3edf532226c4f972f1605b
fixes conversion warnings in visual studio after:
b1674240 Add modified Zeng's method to palette sorting.
src\enc\vp8l_enc.c(296) : warning C4244: '=' : conversion from 'const
uint16_t' to 'uint8_t', possible loss of data
src\enc\vp8l_enc.c(299) : warning C4244: '=' : conversion from 'const
uint16_t' to 'uint8_t', possible loss of data
Change-Id: I981b1ba4912edbbafbd49f1f5b1043bf12266920
With palette+predictors, cross-color was forced (because of predictors).
No need for cross-color for palettes as R/B==0.
This saves 10 bytes per image that uses palette+predictors.
Change-Id: If2184d16cdabe1e8498009062284ad3e37ef1342
with WebPReplaceTransparentPixels() function signature:
src\enc\picture_tools_enc.c(86): warning C4028: formal parameter 1
different from declaration
Change-Id: I0140d61b0dfebcbb4189707e8f2f4b1af802a4d7
this provides stronger synchronization when pthreads are available as
was done in 'd77bf512 add WEBP_DSP_INIT / WEBP_DSP_INIT_FUNC' for the
other init functions.
Change-Id: I2ffe4e24454d276c2411ece34dca38d23d4756d5
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
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
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
For some exact resonance the over-quantization was exactly
compensating the under-quantization, leading to resonance
and strange patterns.
-> we special-handle the very flat blocks, hopefully for the
greater good (and not just the bad-resonance case).
For 'fast mode' (-m 3 or less), we just pay special attention
to the border of the image, where the oscillation / instability
usually starts. For the inner part of the image, since we're not
doing rd-opt, it's harder to fix anything.
Overall, on 'regular' images, the change is written the noise,
often leading to overall faster encoding (because of the short-cut).
BUG=webp:432
Change-Id: Ifaa8286499add80fd77daecf8e347abbff7c3a15
no change in object code
from clang-7 -fsanitize=implicit-integer-truncation
implicit conversion from type 'int' of value -16 (32-bit, signed) to
type 'uint8_t' (aka 'unsigned char') changed the value to 240 (8-bit,
unsigned)
Change-Id: Ia7cbaad247ab22b505b7f98b1247219c024f6db0
