Loading and displaying volumes : a data-concerned approach

Hello Haehn,

I tried to to display medical CT scan volumes made by my company, and i've come to notice that the parsing time is horribly long with 512x512x134 voxel maps ! I went through your code for X.volume and figured the reason of it : all the slices are computed at file loading and parsing.

So I tried another approach : at parsing, save the voxel map and only create 3 slices, and then move them and update their texture at each move of a slice. Then you can choose to save the already computed textures or not (I don't for memory saving).

I've implemented it with the following characteristics :

When the user moves only one slide, just the texture and the position of this slice are computed (mouse move after slice selection)
When the user moves all the slices (double-clic for me), they are all recomputed together (only 1 pass on the arrrayBuffer to compute the 3 slices)
hen the user moves a slice with keyboard or mousewheel pixel by pixel, I buffer the moves for max 100ms or 3px to avoid latency

Here is a result of my tests :

Very short load with only copying the arrayBuffer read from a file (Dicom, ...) : about 1-2s for a 512x512x134 volume
Instant computation of the textures when slices' coordinates change on a AMD E-300 Dual Core(median CPU) with an AMD HD 6300 Graphics (weak GPU) and 4GB RAM.
I only had to change the X.volume and X.slice classes (+interactors) but I don't have volumeRendering, etc...
Without latency, I could change the interactor so the slices always move in the good 3D direction according to the mouse move

So I was wondering if you'd be interested to explore this option ? With adding for ex a new volume class and an option for the parsing. Indeed, the convenience of this one is that the computations are fully transparent for the user (no long loading time, no latency!).

xtk / X

Loading and displaying volumes : a data-concerned approach #99