-
Notifications
You must be signed in to change notification settings - Fork 1k
[v4] suppress console.error while creating InferenceSession #1468
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: v4
Are you sure you want to change the base?
Conversation
|
Thanks for the PR! I recall that for V3, the inference session logging options would not work but perhaps they work now? https://onnxruntime.ai/docs/api/js/interfaces/InferenceSession.SessionOptions.html We can then set a global default logging behaviour, without needing to override global console methods. |
|
Unfortunately this does not work. Even with I think it does make sense to set the But for the This warning actually bypasses the session-specific settings. |
|
My solution now sets the default logging level to 4 (fatal). But it can be overwritten with const segmenter = await pipeline("background-removal", "Xenova/modnet", {
device: "webgpu",
session_options: {
logSeverityLevel: 2, // warning
},
});Tis will not only set the onnxrunntime session_options, but also the |
|
|
||
| ONNX_WEB.env.logLevel = LOG_LEVELS[logSeverityLevel]; | ||
|
|
||
| session_options = { ...session_options, logSeverityLevel }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can move the ONNX_WEB.env.logLevel logic to happen during init (similar to how we set default WASM paths (as a good default).
This should hopefully minimize any session_options specific code a user would need to set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually think it makes sense to set the ONNX_WEB.env.logLevel here where I create a new session. Als a transformers.js user I dont really care if the log is a "onnxruntime session log" or a "onnxruntime general log". All I want to do is to create a pipeline and then be able to set the logLevel.
My solutions basically abstracts this decision away by only providing one setting and thats basically the settings that has always been available in the session_options (although very view people actually used that setting in the past I guess).
| // Overwrite `executionProviders` if not specified | ||
| session_options.executionProviders ??= executionProviders; | ||
| // Set `logSeverityLevel` to 4 (fatal) if not specified | ||
| session_options.logSeverityLevel ??= 4; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be good. From my testing, a value of 3 will hide
2025-12-03 00:44:48.937 node[68874:20600323] 2025-12-03 00:44:48.937479 [W:onnxruntime:, session_state.cc:1316 VerifyEachNodeIsAssignedToAnEp] Some nodes were not assigned to the preferred execution providers which may or may not have an negative impact on performance. e.g. ORT explicitly assigns shape related ops to CPU to improve perf.
2025-12-03 00:44:48.937 node[68874:20600323] 2025-12-03 00:44:48.937528 [W:onnxruntime:, session_state.cc:1318 VerifyEachNodeIsAssignedToAnEp] Rerunning with verbose output on a non-minimal build will show node assignments.
but as you say in #1468 (comment), a value of 4 is necessary to hide everything else when running in browser.
Co-authored-by: Joshua Lochner <admin@xenova.com>

I invested some time into #1236 and from what I see there are three ways how we could solve this:
for 3. We (or the ONNX maintainers) would have to make changes directly in their library. This would certainly be the cleanest solution, but we would be dependent on third parties. 2. I would not recommend this, as it could disrupt the copying process if changes are made within the ONNX library.
That's why solution one would be my favorite. It looks a bit messy or hacky, but honestly, I think it's the simplest solution.