Just noticed this Qt Medical SIG.
For your amusement, here's a "video" (actually a huge animated GIF) of a volumetric viewer I threw together (years ago now... good grief 2014-2015 with Qt 5.4) in an attempt to evangelize Qt/QML and scratch some other itches (ie preprocess DICOM data into something that could simply be memory-mapped).
Ah, too big to upload to this forum. Here's a link instead:
https://imgur.com/a/SH2wHkj (don't panic about the "18+" nag)
or direct link to video version
https://i.imgur.com/n8sjpB6.mp4
Alas, my employer balked at the licensing costs and our tame radiologist was horrified by all the bling (the animated view shifting, "glow" highlighting). Medical imaging software was supposed to be boring and static, apparently.
Mostly QML & JavaScript but the volume loader and MPR/MIP renderers were C++ components; I think if QML had given access to OpenGL 3D and 16-bit textures textures (it didn't at the time; not sure about now) I'd have probably done the rendering as a QML shader effect.
Not shown, but there was also a volume-picking menu which would start pre-loading (into disk-cache RAM) a volume as soon as you even mouse-overed it. By the time you clicked on it, it'd already be there to be instantly memory-mapped. And the fact volumes would hang around disk-cache RAM meant you could click around between several volumes with negligible switching time (if you had enough RAM)... which blew away systems which would insist on reloading volumes from DICOM from scratch every time.
Just to update with some more...
Code is in the public repository at https://bitbucket.org/timday/voltoy/ .
I just bumped the ./MAKE-linux script up from using Qt 5.4 to Qt 5.15.15 and it built and ran just fine (not tried Mac or Windows). Not bad for almost a whole decade elapsed untouched.
To do anything interesting, it needs some volume data in - by default - the ./vol directory. There's some other stuff in the repository (python, GDCM) to fetch some "industry standard" test DICOM from https://www.osirix-viewer.com/resources/dicom-image-library/ and process it into VolToy's "flat" format but I've not tested that (looks like the source URLs have changed from what the scripts/makefiles expect though)... I still had some old processed data on disk. Short story is VolToy wants files named things like PHENIX_1_full-361x512x512-0_700x0_424x0_424.vol which would be raw 16-bit data (no header bytes of any sort) for 361 512x512 slices with 0.7mm x 0.424mm x 0.424mm voxels. (I thought that was quite cunning: putting all the needed metadata in the filename avoided the memory-map having to worry about a header and where the data started in the file).
Just playing with it again now reminds me of one thing I learned from it: using SVG for icons is great for scalability... until you animate the size of the menus those icons are used in. Then the need to re-render the SVG as it's needed at a flurry of different sizes rather destroys the "velvet" framerate, at least on the rather old PC I'm on currently. Could probably be worked round with a bit of clever QML caching and scaling a bitmap for the duration of the resizing animation.
