You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On a Blazor WebAssembly build where OpenCvSharp.dll is excluded from AOT and runs under the Mono interpreter (a workaround for a separate mono-aot-cross crash, see shimat/opencvsharp_blazor_sample#8), calling Cv2.DrawMatches(...) crashes the whole WASM runtime instead of throwing a catchable .NET exception.
Repro context
In shimat/opencvsharp_blazor_sample's Feature Matching sample, after successfully running AKAZE.DetectAndCompute and BFMatcher.Match on two images, calling:
Cv2.DrawKeypoints (5 parameters: InputArray, IEnumerable<KeyPoint>, InputOutputArray, Scalar?, DrawMatchesFlags) works fine under the same interpreted-execution conditions.
Cv2.DrawMatches has a much larger P/Invoke signature (Mat, IEnumerable<KeyPoint> x2, Mat, IEnumerable<DMatch>, Mat, Scalar? x2, IEnumerable<byte>?, DrawMatchesFlags — 10 parameters total), which suggests Mono's interpreter has a limitation marshalling P/Invoke signatures past some complexity/parameter-count threshold, rather than anything specific to this one method.
Current workaround in the sample: avoid Cv2.DrawMatches entirely and draw the side-by-side comparison + correspondence lines manually with Cv2.Line/Cv2.Circle/Mat ROI indexing instead.
Ask
This may ultimately be a Mono/wasm interpreter limitation (arguably better filed against dotnet/runtime) rather than something fixable in OpenCvSharp itself, but filing here first since the immediate practical impact is "OpenCvSharp API X can't be called on wasm-under-interpreter." Any guidance on which complex-signature P/Invoke declarations are known-safe on wasm (or whether this should move to dotnet/runtime) would help other consumers running OpenCvSharp under the same AOT-exclusion workaround.
Summary
On a Blazor WebAssembly build where
OpenCvSharp.dllis excluded from AOT and runs under the Mono interpreter (a workaround for a separate mono-aot-cross crash, see shimat/opencvsharp_blazor_sample#8), callingCv2.DrawMatches(...)crashes the whole WASM runtime instead of throwing a catchable .NET exception.Repro context
In shimat/opencvsharp_blazor_sample's Feature Matching sample, after successfully running
AKAZE.DetectAndComputeandBFMatcher.Matchon two images, calling:hangs/crashes the page. Browser console shows:
Notes / narrowing
DrawMatchesdoesn't touchUMatinternally.Cv2.DrawKeypoints(5 parameters:InputArray,IEnumerable<KeyPoint>,InputOutputArray,Scalar?,DrawMatchesFlags) works fine under the same interpreted-execution conditions.Cv2.DrawMatcheshas a much larger P/Invoke signature (Mat,IEnumerable<KeyPoint>x2,Mat,IEnumerable<DMatch>,Mat,Scalar?x2,IEnumerable<byte>?,DrawMatchesFlags— 10 parameters total), which suggests Mono's interpreter has a limitation marshalling P/Invoke signatures past some complexity/parameter-count threshold, rather than anything specific to this one method.Cv2.DrawMatchesentirely and draw the side-by-side comparison + correspondence lines manually withCv2.Line/Cv2.Circle/MatROI indexing instead.Ask
This may ultimately be a Mono/wasm interpreter limitation (arguably better filed against dotnet/runtime) rather than something fixable in OpenCvSharp itself, but filing here first since the immediate practical impact is "OpenCvSharp API X can't be called on wasm-under-interpreter." Any guidance on which complex-signature P/Invoke declarations are known-safe on wasm (or whether this should move to dotnet/runtime) would help other consumers running OpenCvSharp under the same AOT-exclusion workaround.