by SuboptimalEng on 4/21/24, 4:40 PM with 37 comments
Code should be easy to get started with for anyone familiar with the JS ecosystem.
Questions for the HN community: I spent 20-25% of the entire time just setting up the project and fighting issues with the JavaScript ecosystem. This experience has made me consider learning Cpp, Metal, and XCode. Has anyone made the transition from WebGL/TS to Cpp or done it the other way around? What was your experience with it? And what about debugging? That's a big issue with WebGL.
As for now, I'm thinking about picking up WebGPU next because it has an up-and-coming debugger made by Brendan Duncan[0] that looks promising.
Edit: Anyone know why MRI data is sent via CDs and not the web? I started working on this project specifically because some people close to me got MRI scans and received CDs of their results. I know that some MRI data can be huge so downloading over the web doesn't make sense, but anything under 64MB should be sent over the web, no? For reference, I believe most MRI data can be under 250MB[1].
[0] https://github.com/brendan-duncan/webgpu_inspector
[1] https://www.researchgate.net/figure/Typical-image-dimensions...
by danjl on 4/21/24, 7:11 PM
The medical industry moves slowly. Medical data is often covered by HIPAA, which is why it is often not available easily on the web. Using CDs is just an artifact of their slow movement through technology.
by azeemba on 4/21/24, 8:54 PM
Here is my summary of it[1] and the original paper[2] I found this in
[1] https://azeemba.com/posts/homomorphic-encryption-with-images...
by a1371 on 4/21/24, 5:22 PM
I recently tried Metal a bit. Some features are only available for visionOS (the headset) and not iOS or macOS and vice versa.
by Eduard on 4/21/24, 7:59 PM
I was provided MRI DICOM files a month ago via the radiology office's used SaaS platform, Sectra PatientPortal.
After the MRI session I was given a login code. Back home, I could use that code on the Sectra PatientPortal.
It provides a very basic DICOM image web viewer (contrast/dynamic range modification and slice scrolling, four windows), albeit 2D only, and download of the DICOM files as well as PNG exports.
I am looking for a web-based or Linux-based FLOSS DICOM viewer, but couldn't find any professional program so far.
by fargiolas on 4/22/24, 12:26 PM
by swaginator on 4/23/24, 11:50 PM
Also I love your videos. The internet is a smaller place than it seems.
by _akhe on 4/21/24, 6:33 PM
I really like how you organized your project. As someone who's developed with Three.js for years both imperatively and in a highly-declarative way using R3F I'm always interested to see different approaches to architecture/organization.
by lukko on 4/21/24, 5:29 PM
Related - a while I made a process to convert DICOM / MRI files to voxels for printing at the native resolution of 3D printers [0]. It means you can preserve all the fine detail of the scans, rather than converting to a mesh (segmentation).
On the CD question - it's probably because there is little incentive to build a secure / cross platform solution for patients to access their scans. The CD model is very outdated, but does work, and there is no need for HIPAA compliance even though a CD isn't very secure.
by karxxm on 4/22/24, 8:17 AM
The volume rendering engine I have been working on uses a histogram for the value distribution, and on top of it, one can draw lines that indicate the opacity. Additionally, one can set colors to the control points, which are then linearly interpolated for the given ranges.
by simonbarker87 on 4/21/24, 5:30 PM
by hilti on 4/21/24, 5:52 PM
At first I thought you‘ve been using ImGUI as your interface looks similar.
Maybe that‘s a good starting point for your CPP career.
by cnotv on 4/23/24, 10:20 AM
by adfm on 4/21/24, 5:25 PM
by stonerri on 4/21/24, 8:48 PM
by Twinklebear on 4/21/24, 8:52 PM
Working in WebGL/JS is nice since you can deploy it everywhere, but it can be really hard for graphics programming as you've found because there are very few tools for doing real GPU/graphics debugging for WebGL. The only one I know of is [1], and I've had limited success with it.
WebGPU is a great next step, it provides a modern GPU API (so if you want to learn Metal, DX12, Vulkan, they're more familiar), and modern GPU functionality like storage buffers and compute shaders, not to mention lower overhead and better performance. The WebGPU inspector [2] also looks to provide a GPU profiler/debugger for web that aims to be on par with native options. I just tried it out on a small project I have and it looks really useful. Another benefit of WebGPU is that it maps more clearly to Metal/DX12/Vulkan, so you can use native tools to profile it through Chrome [3].
I think it would be worth learning C++ and a native graphics API, you'll get access to the much more powerful graphics debugging & profiling features provided by native tools (PIX, RenderDoc, Nvidia Nsight, Xcode, etc.) and functionality beyond what even WebGPU exposes.
Personally, I have come "full circle": I started with C++ and OpenGL, then DX12/Vulkan/Metal, then started doing more WebGL/WebGPU and JS/TS to "run everywhere", and now I'm back writing C++ but using WebGL/WebGPU and compiling to WebAssembly to still run everywhere (and native for tools).
With WebGPU, you could program in C++ (or Rust) and compile to both native (for access to debuggers and tools), and Wasm (for wide deployment on the web). This is one of the aspects of WebGPU that is most exciting to me. There's a great tutorial on developing WebGPU w/ C++ [4], and a one on using it from JS/TS [5].
[0] https://www.willusher.io/webgl/2019/01/13/volume-rendering-w...
[1] https://spector.babylonjs.com/
[2] https://github.com/brendan-duncan/webgpu_inspector
[3] https://toji.dev/webgpu-profiling/pix