Volume Rendering not working

#1

Operating system: Windows 10
Slicer version: 4.8.1
Expected behavior: I am following the CT Thorax Abdomen tutorial to have a first look at volume rendering. The expected behavior is described in the tutorial.

Actual behavior: When I click on the eye-icon in the Volume Rendering module, all I see is that the bounding box changes color to white, and a coordinate system appears. There is no rendering of the data. I tried using CPU or GPU rendering, nothing changed. I also made sure in the NVIDIA driver settings that Slicer is using the GPU and not the integrated chip. I am using a Dell Precision mobile workstation with a Quadro M1200 GPU.

Any thoughts?

Christian

#2

The default transfer functions might not show your data. Try many presets and see if any of them displays your data.
What is the volume’s scalar range? You can check it in the Volumes module.

#3

Also try the current nightly build, which has a very different volume rendering back end and probably works differently.

#4

Thanks for the quick replies, it was as usual a user error. I clicked on the wrong eye icon. Sorry, I am new to 3D Slicer.

#5

If you have any suggestions about how to make it more straightforward for new users we’d be glad to hear it.

#6

Sure!

One pitfall is that the eye icon is very small and easily looked over. It kind of blends in with the down arrows that are in the same column if there are any sub-menus. I just didn’t even look there for the icon. Even when it was pointed at in the tutorial I linked, it didn’t occur to me that is where the eye icon would be. In addition, the eye icon for display ROI is in a different column, but that one has a label.

Also, when I select the Volume Rendering module, and it auto-selects a volume to be displayed, I would expect that it displays automatically, as soon as I select the module. Of course here it is important to have a good preset transfer function selected. You can maybe use a simple ramp that uses the histogram to set min and max values, e.g. 10% - 90% of the histogram.

Just some ideas.

#7

By the way @cpinter, I love the ability to do the multiple volume rendering, but now I find it hard to toggle between two volumes using the Volume Rendering module (you need to select one, turn it off, then select the other and turn it on). I was thinking that perhaps now the Data (Subject Hierarchy) tab would be able to control the volume visibility.

And with multiple visible volumes it’s easy to get confused about which volume’s rendering properties are selected for editing so you can mess up your settings by accident.

If you have more cycles to work on that module GUI I have more ideas :grinning:

#8

On that note, when I switch to multi-volume rendering from GPU raycasting, for my data it goes from being like this
image
to this
image
with todays nightly. Whatever I try with the ramp doesn’t fix this.

#9

There is no shading implemented yet in multi-volume rendering so you won’t be able to get an image like the one above. By looking at the difference between the renderings, there also seems to be a difference in sampling distance. We can get back to this after shading is implemented.

If proper multi-volume rendering (with shading) is important for you then it could be useful to let Kitware folks know. There is a better chance that it will be implemented sooner if there is a confirmed need from the community. Of course it is even better if they get some small funding for the remaining tasks (which should not be that much).

#10

I guess we did not want to promote multi-volume rendering very much until shading is implemented, to avoid disappointing users. Once multi-volume rendering can produce images comparable to single-volume rendering, we can add a tree view with eye icons in volume renderer module (and also make volume rendering easier to access from subject hierarchy tree).

It would be useful to implement an intelligent default preset selection (we could guess from voxel unit, scalar range, etc.) because then clicking the eye icon would show nice rendering without the need to select a preset and tune intensity offset.

#11

In the current VR, we use w/l settings and the LUT associated with the volume to initialize the transfer function. The assumption was that people would look at the slices first and adjust their appearance before going into the volume rendering module.

1 Like
#12

In my experience that heuristic works in general but the lower
threshold ends up showing too much of the background noise
Ron

#13

@lassoan, the problem I’m referring to is that the changed behavior of visibility management happens for all rendering modes, not just the multi-volume rendering. Previously (e.g. 4.8.1), the volume selector acted like a radiobutton, where selecting a volume made it visible and the others invisible, which makes sense for renderers that don’t support multiple volume rendering. Now, visibility is sticky with the volume, which makes sense for the multi-volume mode but not for the other modes.

Volume/Volume Rendering
#14

There are definitely things to improve in volume rendering. Multi-volume rendering is still experimental (does not render correctly with the regular mappers, and there is no shading with the multi-volume mapper), and cannot be considered complete. I could add an altered subject hierarchy tree view that shows/hides volume rendering with the eye icon, but as Andras says it may be a bit premature. Maybe I coud implement the old way of functioning until then and add an option for that in Application Settings? Also you can show/hide volume rendering in the Data module (SH tree) by right-clicking the eye icon and toggle volume rendering.

1 Like
#15

I think this would be the most logical for the near future - it makes no sense currently to have multiple volumes marked as visible when they cannot be composited.

Logic could be: when a new volume is selected in the combo box all other volumes are made invisible unless the multiple-volume renderer is selected.

#16

I think the current implementation is clear to use (whenever you click the eye icon, a volume is shown) and implement (old behavior was very buggy, render volume often switched randomly when changing parent transform or loading a scene), and allows rendering of multiple volumes (which can work quite well even with simple volume renderer when the volumes are transparent). I think these advantages overweigh the inconvenience of a single extra click and potential user confusion about compositing errors.

#17

The old behavior had some problems, but my original issue with the current behavior still stands: if your goal is to compare to volume renderings it’s multiple confusing clicks (turn off current, select new, turn it on). And if the currently selected volume isn’t the visible one it’s prone to changing the lookup table and not seeing any update (which is confusing).

#18

About the accidental lookup table manipulation: we could disable the rest of the panel when the selected volume is not shown.

#19

The behavior is the same for markups, segmentations, volumes, transforms, plots, etc.: you select a node and then adjust visibility. Models and annotations have a tree instead of a node combobox, which has a direct visibility shortcut as well, but otherwise it works the same way.

Why would we want to invent something new for volume rendering?

Would it help if we replaced the node selector combobox by a tree (similar to models)?

Would it help if we added a special “single” mode to the eye icon in volume rendering module (can be enabled with long click)? It would hide all other volumes when eye icon is clicked. This mode would be a purely GUI-level option - rendering of multiple volumes could be still possible by using Data module, by loading a scene, etc. (or by disabling “single” mode).

#20

The difference, at least now, is that unless the multi-volume renderer is selected, the volumes do not composite correctly so it doesn’t make sense to have them visible at the same time. I agree that once multivolume rendering is working well it could become the default and then things should be exactly parallel to the model/segmentations/etc interfaces.

As long as the best renderers available only really support single-volume rendering (as in the current CPU and GPU options) then we should have an easy way to use them that is consistent with that limitation.