Skip to content

wasm: JPEG/PNG/TIFF codecs are disabled, causing silent empty-Mat decode failures #2043

Description

@shimat

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions