In the recent 3 months, since the @kephale’s SciView Hackathon I have been trying to get GPU volume rendering working for Biiiiiigggg volumes (i.e., too large to fit into RAM, and certainly too large to fit on the GPU).
This is now in a state, where I’m comfortable with letting people play with it.
(In reality, I’m going on holiday tomorrow, and I wanted to push this out before…)
I just uploaded it to update site http://sites.imagej.net/BigVolumeViewer/
(Source code is here if you are really interested: https://github.com/tpietzsch/jogl-minimal
It is still not properly cleaned up. When it is, it will be split into multiple repos and moved to the appropriate places…)
If you add Fiji update site http://sites.imagej.net/BigVolumeViewer/ and update, you will then have a Plugins > BigDataViewer > Volume Rendering Tech Demo menu entry.
That opens the following dialog:
In there just select the XML file of a BigDataViewer XML/HDF5 dataset and leave everything unchanged.
(Backends besides HDF5 will also work, but data must be 16bit, and if it’s not multi-resolution, it will be painful.)
Then something like this should pop up:
This is basically a BigDataViewer window, but doing (Max Intensity Projection) volume rendering using OpenGL.
Most of the BDV mouse and key actions work. Navigation can be a bit confusing, because you don’t see where the “screen plane” is, but still navigation is centered around that. “R” resets transform to initial.
“1”, “2”, “3” etc to switch channels, “F” to toggle fused/single channel mode, “shift 1”, “shift 2”, etc to show/hide channels in fused mode.
BDV brightness and visibility dialogs also work (“S”, “F6”):
This is all still badly hacked together, but it would be great if some of you could try it!!!
In particular, I would be interested in OS/hardware configurations that don’t work. (This uses mostly ancient OpenGL stuff that should really work everywhere, but you know how it is…)
Some notes on the other settings in the initial “Volume Rendering Tech Demo” dialog.
- Render width/height: Stuff is rendered to a offscreen surface of this size, and then scaled up to fill the window.
Dithering: Especially if multiple sources are rendered at the same time, things can get slooooow (at least on my Macbook GPU…) if rendered at full resolution. Dither window size “4x4” means: draw only one pixel in each 4x4 window. Then if there is time left, draw another pixel in each 4x4 window, then another, until target time is up. Interpolate the rest. Continue in the next frame, until all 4x4 pixels have been drawn. Number of dither samples: Pixels are interpolated from this many nearest neighbors when dithering. This is not very expensive – turn it up to 8.
Dithering is a two-edged sword. Although it is a lot faster to draw only every 16th pixel, iterating this until all 16 are filled is a lot slower than rendering them all in the first place. My explanation is that still in each iteration you touch enough texture data from all over the place to make caches less efficient… (?)
So maybe if you have a decent GPU, you don’t need it…
- GPU cache size (in MB) It helps to turn this up as much as possible, obviously… Depends on how much memory your GPU has. For example, my GPU has 1GB, so I can go maybe up to 600 MB, but not more (the OS and other programs share need some of that memory too!)
The rest is not so interesting.
- I’m working with @skalarproduktraum to integrate this into scenery and @kephale’s SciView. This will probably be the main way that most users will access it. This is already underway. We had a session today with @skalarproduktraum, and we are optimistic… This will happen very soon.
- At the moment the type of imglib2 data you can throw at it is limited. It has to be
UnsignedShortType, and it has to come from
CellImgs. So a lot of stuff that BigDataViewer (and bdv-vistools) can do, this cannot do yet.Eventually, I want every reasonable imglib2 type to work with this. Also it needs to pick up on changes in the images and update the data in the GPU cache accordingly. The dream is, that this will simply work out of the box in bdv-vistools, without any changes to existing code. There will be just a shortcut to switch to volume mode, and thats that… But this is at least one year away, I would say.
I almost forgot the most important shortcuts:
“B” adds a textured box in a random location.
“shift B” removes a random existing box.
Have fun …