Summary
The wasm build's .github/workflows/wasm.yml explicitly disables JPEG, PNG, and TIFF support:
-DWITH_JPEG=OFF \
-DWITH_TIFF=OFF \
-DWITH_PNG=OFF \
As a result, Mat.FromImageData / Cv2.ImDecode silently return an empty Mat (no exception thrown) for otherwise perfectly valid JPEG or PNG byte arrays on this wasm build. Cv2.GetBuildInformation()'s Media I/O section confirms this - it lists WEBP and JPEG 2000 as build, but has no entry at all for JPEG/PNG/TIFF (not even NO):
Media I/O:
ZLib: build (ver 1.3.2)
WEBP: build (ver decoder: 0x0210, encoder: 0x0210, demux: 0x0107)
AVIF: NO
JPEG 2000: build (ver 2.5.3)
GIF: YES
HDR: YES
SUNRASTER: YES
PXM: YES
PFM: YES
This is a real-world blocker: a Blazor WebAssembly sample app (shimat/opencvsharp_blazor_sample) that lets users upload their own photo hit this directly - an uploaded JPEG decoded to a 0x0 Mat with no error, which was only diagnosable by confirming byte-for-byte that the input was a well-formed JPEG (correct SOI/APP0 header, correct EOI trailer) before concluding the codec itself was missing. The only workaround was hand-encoding an uncompressed BMP in JavaScript before handing bytes to OpenCV, since BMP is the only image format confirmed to decode on this build.
Ask
Could JPEG and PNG support be enabled for the wasm build (-DWITH_JPEG=ON -DWITH_PNG=ON), and TIFF too if practical? These are two of the most common image formats on the web, so their absence is a significant surprise for anyone consuming OpenCvSharp5.runtime.wasm and decoding user-supplied images (as opposed to only ever loading from a known-good bundled asset).
If they were disabled because the bundled 3rdparty libjpeg-turbo/libpng/libtiff sources don't build cleanly under Emscripten (e.g. missing SIMD/NASM assembly support, or some dependency chain issue), it would help a lot to at least note that in a comment next to the flags in wasm.yml, so the next person who hits this - via Mat.FromImageData silently failing, with no exception pointing at the real cause - doesn't have to rediscover it from scratch.
Environment
- OpenCvSharp5.runtime.wasm 5.0.0.20260703
.github/workflows/wasm.yml on main as of this writing
Summary
The wasm build's
.github/workflows/wasm.ymlexplicitly disables JPEG, PNG, and TIFF support:As a result,
Mat.FromImageData/Cv2.ImDecodesilently return an emptyMat(no exception thrown) for otherwise perfectly valid JPEG or PNG byte arrays on this wasm build.Cv2.GetBuildInformation()'sMedia I/Osection confirms this - it listsWEBPandJPEG 2000asbuild, but has no entry at all for JPEG/PNG/TIFF (not evenNO):This is a real-world blocker: a Blazor WebAssembly sample app (shimat/opencvsharp_blazor_sample) that lets users upload their own photo hit this directly - an uploaded JPEG decoded to a 0x0
Matwith no error, which was only diagnosable by confirming byte-for-byte that the input was a well-formed JPEG (correct SOI/APP0 header, correct EOI trailer) before concluding the codec itself was missing. The only workaround was hand-encoding an uncompressed BMP in JavaScript before handing bytes to OpenCV, since BMP is the only image format confirmed to decode on this build.Ask
Could JPEG and PNG support be enabled for the wasm build (
-DWITH_JPEG=ON -DWITH_PNG=ON), and TIFF too if practical? These are two of the most common image formats on the web, so their absence is a significant surprise for anyone consumingOpenCvSharp5.runtime.wasmand decoding user-supplied images (as opposed to only ever loading from a known-good bundled asset).If they were disabled because the bundled 3rdparty
libjpeg-turbo/libpng/libtiffsources don't build cleanly under Emscripten (e.g. missing SIMD/NASM assembly support, or some dependency chain issue), it would help a lot to at least note that in a comment next to the flags inwasm.yml, so the next person who hits this - viaMat.FromImageDatasilently failing, with no exception pointing at the real cause - doesn't have to rediscover it from scratch.Environment
.github/workflows/wasm.ymlonmainas of this writing