Volume rendering in radiology: some new videos
category: general [glöplog]
looks like an ASD demo without the progrock soundtrack!
an octree would need to be calculated (on the cpu?) each time the threshold changes. And that would have some real effect (probably as in 2,3x faster) if the datasets were really sparse (they are sometimes, but not always).
I remember reading a fairly old paper on optimizations for direct volume rendering of medical data (back in the days when it was pretty impossible to do all that in interactive framerates) quoting 30-50% framerate increase which I now believe is not worth the effort (and the memory overhead, which is my only concern at the moment). I have a scheme for space skipping similar to one employed by iq (distance functions) which I use in a situation where the threshold in surface reconstruction is fixed. This gives me a speed up of 2x - 'just buy a faster card' :-)
I remember reading a fairly old paper on optimizations for direct volume rendering of medical data (back in the days when it was pretty impossible to do all that in interactive framerates) quoting 30-50% framerate increase which I now believe is not worth the effort (and the memory overhead, which is my only concern at the moment). I have a scheme for space skipping similar to one employed by iq (distance functions) which I use in a situation where the threshold in surface reconstruction is fixed. This gives me a speed up of 2x - 'just buy a faster card' :-)
Navis: That's why I said min/max octree. If my general understanding is right that you've got a voxel field full of numbers and simply compare against a threshold to determine where the surface is, you don't need to recalculate anything - just store the minimum and maximum values of the eight children in the parent node. That way all compare operations can easily traverse the octree down to the lowest level without too much hassle.
IMHO the advantage isn't so much the modest performance increase but the fact that it should (at least in my mind :) be possible to go to maximum raymarching resolution without too much effort. That'd at least remove all the too-small-to-hit artifacts :)
IMHO the advantage isn't so much the modest performance increase but the fact that it should (at least in my mind :) be possible to go to maximum raymarching resolution without too much effort. That'd at least remove all the too-small-to-hit artifacts :)
Navis: I think it's worth trying some alternative controllers. If you show it using a standard keyboard + mouse, it looks the same as everyone else's product (well, from this angle at least). If you show it using something a bit more intuitive, different + cool, it makes the product seem more exciting and new. It might be a cheap gimmick, but first impressions do count and this could add some extra impressiveness :)
The space navigators are reasonably cheap + have a good reputation (not tried on personally), a multi-touch screen would be really cool but more pricey (and it'd need some UI work I bet). If you want to play with multitouch, get an ipod touch - there's an app for it which will let you use it as a touch controller, sending data via OSC.
With any of those, I'd say it's probably more important that it looks cool and easy to use rather than actually being so ;)
Btw, I reckon the next level for this stuff will be realtime data so you have a live view of the patient in 3d. Is it possible yet?
The space navigators are reasonably cheap + have a good reputation (not tried on personally), a multi-touch screen would be really cool but more pricey (and it'd need some UI work I bet). If you want to play with multitouch, get an ipod touch - there's an app for it which will let you use it as a touch controller, sending data via OSC.
With any of those, I'd say it's probably more important that it looks cool and easy to use rather than actually being so ;)
Btw, I reckon the next level for this stuff will be realtime data so you have a live view of the patient in 3d. Is it possible yet?
Quote:
The space navigators are reasonably cheap + have a good reputation (not tried on personally)
Try one. Even the cheapest model is excellent.
(I had written a long post but the monster of pouet has eated it. Damn it)
Anyway, the zest:
kb_: I think that an octree is a good idea for visibility determination on large datasets that wouldn't fit all in memory. Currently my scheme will guarantee that each voxel along the raycasting line is sampled. I can drop that to x0.5 (one every two) and still get fine results in 95% of cases with CT. It doesn't look that good when I change the threshold on the fly *while navigating*, hence the aliasing in some of the videos.
psonice/hollowman: It is in my shopping list this gadget. It is just that sometimes it is hard to change how the industry works (which reminds me of people still using norton commander because they've been doing that for the past 20 years).
Since people have been asking me to give a bit more insight on the workings of the raycaster I'll do that soon in another post.
Anyway, the zest:
kb_: I think that an octree is a good idea for visibility determination on large datasets that wouldn't fit all in memory. Currently my scheme will guarantee that each voxel along the raycasting line is sampled. I can drop that to x0.5 (one every two) and still get fine results in 95% of cases with CT. It doesn't look that good when I change the threshold on the fly *while navigating*, hence the aliasing in some of the videos.
psonice/hollowman: It is in my shopping list this gadget. It is just that sometimes it is hard to change how the industry works (which reminds me of people still using norton commander because they've been doing that for the past 20 years).
Since people have been asking me to give a bit more insight on the workings of the raycaster I'll do that soon in another post.
hey ! megathanks.