Wasmtime GitHub notifications bot (May 30 2025 at 07:51): Wasmtime GitHub notifications bot (May 30 2025 at 07:51):yamt opened issue #10867:
currently the example outputs something like
Found results, sorted top 5: [InferenceResult(885, 0.3958259), InferenceResult(904, 0.36464667), InferenceResult(84, 0.010480272), InferenceResult(911, 0.0082290545), InferenceResult(741, 0.0072448305)] spacetanuki%but it's quite wrong because of dimension mismatch.
ie. while the model expects 3x244x244, the file is 244x244x3.if i transpose tensor.bgr to 3x244x244, it produces:
Found results, sorted top 5: [InferenceResult(963, 0.7113058), InferenceResult(762, 0.070707425), InferenceResult(909, 0.036355816), InferenceResult(926, 0.01545616), InferenceResult(567, 0.015344027)]it's more reasonable and similar to what i got when running the same model with https://github.com/openvinotoolkit/open_model_zoo/tree/master/demos/classification_demo/python. (see the below screenshot)
<img width="752" alt="Image" src="https://github.com/user-attachments/assets/050d3860-f60f-4263-97a2-75f1b73434db" />
Wasmtime GitHub notifications bot (May 30 2025 at 07:51):yamt edited issue #10867:
currently the example outputs something like
Found results, sorted top 5: [InferenceResult(885, 0.3958259), InferenceResult(904, 0.36464667), InferenceResult(84, 0.010480272), InferenceResult(911, 0.0082290545), InferenceResult(741, 0.0072448305)] spacetanuki%but it's quite wrong because of dimension mismatch.
ie. while the model expects 3x244x244, the file is 244x244x3.if i transpose tensor.bgr to 3x244x244, it produces:
Found results, sorted top 5: [InferenceResult(963, 0.7113058), InferenceResult(762, 0.070707425), InferenceResult(909, 0.036355816), InferenceResult(926, 0.01545616), InferenceResult(567, 0.015344027)]it's more reasonable and similar to what i got when running the same model with https://github.com/openvinotoolkit/open_model_zoo/tree/master/demos/classification_demo/python. (see the below screenshot)
<img width="752" alt="Image" src="https://github.com/user-attachments/assets/050d3860-f60f-4263-97a2-75f1b73434db" />
Wasmtime GitHub notifications bot (May 31 2025 at 00:00):abrown commented on issue #10867:
You're probably right that there could some mismatch in the artifact we're using for these examples. This example is quite old and things may have changed in the interim. What steps are you using to reproduce? And everything works if you just regenerate the
.bgrfile--what tool did you end up using?
Wasmtime GitHub notifications bot (Jun 01 2025 at 22:13):yamt commented on issue #10867:
You're probably right that there could some mismatch in the artifact we're using for these examples. This example is quite old and things may have changed in the interim.
i guess it has always been broken as the example output in README.md seems wrong.
What steps are you using to reproduce? And everything works if you just regenerate the
.bgrfile--what tool did you end up using?steps to reproduce the issue:
- download files as following the README.md.
- cargo build --target wasm32-wasip1
export DYLD_LIBRARY_PATH="$(brew --prefix)/lib" wasmtime run --wasi=nn --dir=fixture target/wasm32-wasip1/debug/wasi-nn-example.wasm(wasmtime and openvino are from homebrew)fix:
"fix" the bgr file with the following onetime-use C program (i will attach the resulted bgr file as well)
#include <stdlib.h> #include <unistd.h> int main() { /* transpose 224x224x3 to 3x224x224 */ const int height = 224; const int width = 224; float *p = malloc(height * width * 3 * 4); float *p2 = malloc(height * width * 3 * 4); read(0, p, height * width * 3 * 4); int x; int y; for (y = 0; y < height; y++) { for (x = 0; x < width; x++) { int pos = y * width + x; float b = p[0 + pos * 3]; float g = p[1 + pos * 3]; float r = p[2 + pos * 3]; p2[0 * height * width + pos] = b; p2[1 * height * width + pos] = g; p2[2 * height * width + pos] = r; } } write(1, p2, height * width * 3 * 4); }
Wasmtime GitHub notifications bot (Jun 10 2025 at 21:07):rahulchaphalkar commented on issue #10867:
@yamt I had a chance to look at this, and you are right about the layout mismatch -
The mobilenet model we use has an input tensor expectation of NCHW (1, 3, 224, 224) as seen here, while the image is NHWC.The one place where we know this works is in openvino-rs crate test, and thats the only place we actually test the output results. Here we can also see some explicit layout setups that make this work as we expect.
Given this, I'll make some changes soon addressing some of these things -
- Update example to use witx/wit directly and not wasi-nn layer. Currently this uses a very outdated wasi-nn binding layer.
- Introduce checks if possible in
test-programsfor checking if output matches the expected results, so things like these will be caught- Update the image to the right format
Wasmtime GitHub notifications bot (Jun 11 2025 at 02:01):yamt commented on issue #10867:
thank you for taking a look.
Update example to use witx/wit directly and not wasi-nn layer. Currently this uses a very outdated wasi-nn binding layer.
do you mean to migrate to a newer wasi-nn abi?
well, i'm not happy with it because i was using this example to test other implementation (wamr) which implements an ancient version of the abi. i understand it isn't your business though...
Wasmtime GitHub notifications bot (Jun 11 2025 at 19:44):rahulchaphalkar commented on issue #10867:
Currently, the example uses these wasi-nn rust bindings 0.1.0, which is from 2021, so I was thinking of updating it to either use WIT directly like here, or WITX like here.
But I understand that you actually need this older wasi-nn bindings for your use case?
In that case, I can simply update the image to be right dimensions, and make other changes to tests to check output is correct, and let this example be the way it is for now.
Wasmtime GitHub notifications bot (Jun 11 2025 at 22:58):yamt commented on issue #10867:
Currently, the example uses these wasi-nn rust bindings 0.1.0, which is from 2021, so I was thinking of updating it to either use WIT directly like here, or WITX like here.
the witx one there still seems like a wrapper around the wasi-nn rust bindings. it's newer than 0.1.0 though.
https://github.com/bytecodealliance/wasmtime/blob/a8e0d07000133191659d76aba52f2893fa32792f/crates/test-programs/Cargo.toml#L15do you mean to use wiggle?
But I understand that you actually need this older wasi-nn bindings for your use case?
i don't care wasi-nn rust bindings or its version.
i do care wasi-nn version. (i want to use witx-based one for now.)having said that, as there are siblings of this test available here and there
(eg. https://github.com/second-state/WasmEdge-WASINN-examples/tree/master/openvino-mobilenet-raw)
the version used in this instance isn't critical to me.
Wasmtime GitHub notifications bot (Jun 12 2025 at 20:22):rahulchaphalkar commented on issue #10867:
Yes, the witx one would be updated to
0.6.0wasi-nn rust bindings from current0.1.0for this example, similar to the tests.
Wasmtime GitHub notifications bot (Jun 12 2025 at 23:21):yamt commented on issue #10867:
Yes, the witx one would be updated to
0.6.0wasi-nn rust bindings from current0.1.0for this example, similar to the tests.ok. it makes sense. thank you.
Wasmtime GitHub notifications bot (Jun 27 2025 at 18:56):abrown commented on issue #10867:
Introduce checks if possible in test-programs for checking if output matches the expected results, so things like these will be caught
In talking to @rahulchaphalkar today, I think this comment is a good idea: we should audit the results coming out of these test programs against the results one would get natively. Then we can be a bit more sure that we've configured things correctly prior to inference. And doing this for the test programs could naturally spill over into auditing the examples, too, where I believe this whole issue came up.
Last updated: Dec 06 2025 at 07:03 UTC