Title: 2026.09.22 Weekly Meeting
Next Tuesday, we will be having our next weekly hangout at 10:00 AM ET until 11:00 AM ET.
Anyone is welcome to join at this link: Google Meet meeting
Agenda:
Please post to this thread to put a topic on the agenda! We will try to prioritize agenda items during the meeting.
Thanks
Sam and Ebrahim
Bump: This meeting is tomorrow
I would like to show the result of my experiment of compiling entire Slicer using webassembly and running natively in the browser. The results are quite shocking (in a good way).
It would be good if we could discuss why this change might have happened: Rendering of DICOM image failed with more than 4 volumes since version 12 - #7 by mhouse
Notes from the meeting:
This is experimental work done by Andras over a weekend. All of Slicer, except for Qt, compiled into webassembly and running in a browser! No rendering or computations happen on the server, everything is done locally in user’s the browser, no data leaves the user’s computer.
Python is well supported. Python runs in the browser using Pyodide. The web application has a Python console, Python packages can be installed anytime (pip_install installs packages work from the Pyodide distribution, from PyPI through micropip, or from custom-built packages).
Scripted modules work without changes. Claude created a mock Qt layer to make this pretty seamless.
C++ modules work with no changes to MRML and logic classes. Shared Qt widgets are reproduced by Claude using Vue. Module-specific widgets are recreated by Claude.
Extensions are supported. All extensions that contain only Python scripted modules should work without any source code changes (just need to be repackaged). Very complex extension that contain VTK and ITK based compiled code work well, too (see for example VMTK).
The amount of code generated to achieve this was very small – this is not a re-implementation of everything but reuses the same C++ components that make up Slicer. The only source code that is not shared between desktop and web builds of Slicer are the Qt widgets.
This shows how much can be achieved in a short time in terms of porting slicer functionality to the web browser, and how mature webassembly and pyodide are.
Next steps: integrate necessary patches into upstream repositories, extend to include more modules and extensions.
Code is available at: GitHub - lassoan/SlicerWeb: Run 3D Slicer natively in the web browser · GitHub
@ebrahim What is to maintain the existing default to clip to the background or uncontroversial to change the default to no longer by default clip to the background?
I meant that no one seemed to object to changing the default so that clip to background is off. And Steve and I both explicitly liked the idea.
Agreed, disabling clipping would be useful in most cases (esp. when manually moving / registering multiple volumes in Slice views).
Regarding the blending issue, I also find the current behavior very unnintuitive and not blending the volumes where they don’t overlap would make sense to me.
@lassoan thanks for the demo yesterday and for sharing the code!
I’ll probably repost for next week’s meeting, but I’d like to discuss roadmap / architecture and design for the components that should be refactored in pure VTK C++ so that they can be reused in SlicerWeb / trame-slicer usage.
Looking at the code, I think there are at least the following to factorize and propagate in upstream: