the trailing width % 8 bytes would clear the upper bytes of
alpha_mask as they're done one at a time
since:
49d0280d NEON: implement several alpha-processing functions
Change-Id: Iff76c0af3094597285a6aa6ed032b345f9856aae
It's self contained apart from a dependency on src/webp/types.h and src/dsp/cpu.h
For now it's only set up as an internal library, not an installable one.
Webp doesn't depend on it yet, the code is only duplicated.
Change-Id: I752799894f9d4105d0d296ddebd9f9641181a1ec
msa_macro.h
neon.h
allows the headers to be built / analyzed under different target
configurations
Change-Id: Ibbcfada210b54988aa5279674d53af8e21fd4a97
- prefer https
- metadataworkinggroup.org/com seem to be offline; the web archive link
was obtained from exiftool: https://exiftool.org/TagNames/MWG.html
- fix kramdown link, rubyforge has been gone a long time
- fix png/zlib links
Bug: webp:544
Bug: b/202302177
Change-Id: Id69de4553e7baf00393f12a2c1acb262443a1a93
... 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
Visual Studio added ARM64 support, but requires arm64_neon.h to be
included rather than arm_neon.h. Visual Studio 2019 addressed this so
we'll start with that version and leave a local adapter include for a
follow up.
Bug: webp:539
Change-Id: If975c029dafffba99210b3bb2d670035a83e8105
after:
ece18e55 dsp.h: respect --disable-sse2/sse4.1/neon
WEBP_USE_* will be set when a module is targeting a particular
instruction set, e.g., sse4.1, and not overridden if WEBP_HAVE_SSE41 is
set, as previously this would ignore the case where the instruction set
was disabled via config.h and the HAVE macro was unset.
dsp.h not ensures WEBP_HAVE_* are set when WEBP_USE_* to cover cases
where the files are built without config.h.
Change-Id: Ia1c2dcf4100cc1081d968acb6e085e2a1768ece6
previously this would be overridden if the instruction set was enabled
via -msse4.1, __aarch64__, etc.
Change-Id: I51e87a7da7589c6093d260b848ab41d89ec7b990
similar to '* const', __restrict needs to be included in the
declaration to avoid warnings like:
src\dsp\alpha_processing.c(429): warning C4028: formal parameter 1
different from declaration
this change also moves WEBP_RESTRICT to dsp.h to avoid a circular
dependency between it and utils.h which already includes dsp.h
Change-Id: Ib070d358a372e76fae4be5445ab288940b9baac0
avoids integer overflow in extreme cases:
src/dsp/rescaler.c:45:32: runtime error: signed integer overflow: 129 *
16777215 cannot be represented in type 'int'
#0 0x556bde3538e3 in WebPRescalerImportRowExpand_C src/dsp/rescaler.c:45:32
#1 0x556bde357465 in RescalerImportRowExpand_SSE2 src/dsp/rescaler_sse2.c:56:5
...
Bug: chromium:1196850
Change-Id: I4f923807f106713e113f3eec62a1d1c346066345
VerticalUnfilter_SSE2 has long been disabled due to a crash in an
Android emulator that hasn't reproduced elsewhere (crbug.com/654974).
this synchronizes the code for now to avoid needing to locally edit the
file on import.
Bug: 1141126
Change-Id: Ib61aeab93caaff1759606566b9e499eaac1576cf
this function produces different results from the C code due to
use of double/float resulting in output differences when compared to
-noasm.
Bug: webp:499
Change-Id: Ia039b168c0a66da723fb434656657ba1948db8ae
- Add `-msimd128` to flags to actually enable WebAssembly SIMD
when performing SIMD detection. It's currently required in
addition to `-msse*` / `-mfpu=neon` flags which only perform
translation of corresponding intrinsics to Wasm SIMD ones.
See a discussion at emscripten-core/emscripten#12714 for
automating this and making easier in the future.
- Remove compilation branch that prevented definitions of
`WEBP_USE_SSE` and `WEBP_USE_NEON` on Emscripten even when
SIMD support was detected at compile-time.
- Add an implementation of `VP8GetCPUInfo` for Emscripten which
uses static `WEBP_USE_*` flags to determine if a corresponding
SIMD instruction is supported. This is because Wasm doesn't
have proper feature detection (yet) and requires making separate
build for SIMD version anyway.
Change-Id: I77592081b91fd0e4cbc9242f5600ce905184f506
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
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
missed in a788b49
with clang7+ quiets conversion warnings like:
implicit conversion from type 'int' of value -114 (32-bit, signed) to
type 'uint8_t' (aka 'unsigned char') changed the value to 142 (8-bit,
unsigned)
Change-Id: I52dcd9cd613107f5424177c277785b92430bffb7
with clang7+ quiets conversion warnings like:
implicit conversion from type 'int' of value -114 (32-bit, signed) to
type 'uint8_t' (aka 'unsigned char') changed the value to 142 (8-bit,
unsigned)
Change-Id: I7f08a836ddcf777454dfd5b877a81b62b2abac86
with clang7+ quiets conversion warnings like:
implicit conversion from type 'int' of value -12 (32-bit, signed) to
type 'uint8_t' (aka 'unsigned char') changed the value to 244 (8-bit,
unsigned)
Change-Id: I053c92301e55dcb0cae89a7733636283da942176
