Multi-volume rendering bug

Shading in the multi-volume rendering worked for a while for me, but in this dataset I am getting this error:

Loaded volume from file: C:/Users/amaga/Desktop/Cuke_9.9um_2k__rec_Cor0556 Segment_1_1.nrrd. Dimensions: 326x805x343. Number of components: 1. Pixel type: unsigned char.
vtkMRMLScene::Clear
"Volume" Reader has successfully read the file "C:/Users/amaga/Desktop/Cuke_9.9um_2k__rec_Cor0556 Segment_1_1.nrrd" "[0.19s]"
Loaded volume from file: C:/Users/amaga/Desktop/Cuke_9.9um_2k__rec_Cor0556 Segment_2.nrrd. Dimensions: 648x2233x780. Number of components: 1. Pixel type: unsigned char.
vtkMRMLScene::Clear
"Volume" Reader has successfully read the file "C:/Users/amaga/Desktop/Cuke_9.9um_2k__rec_Cor0556 Segment_2.nrrd" "[1.29s]"
The VTKEvent( 17000 ) triggered by vtkObject( vtkMRMLScalarVolumeNode )  doesn't return data of type vtkObject. 
The slot ( "1onDisplayNodeModified(vtkObject*, vtkObject*)" ) owned by  QObject( "" )  may be incorrect.
void __cdecl qSlicerSubjectHierarchyPluginLogic::onDisplayNodeModified(class vtkObject *,class vtkObject *) : Invalid object type calling display node modified event
The VTKEvent( 17000 ) triggered by vtkObject( vtkMRMLScalarVolumeNode )  doesn't return data of type vtkObject. 
The slot ( "1onDisplayNodeModified(vtkObject*, vtkObject*)" ) owned by  QObject( "" )  may be incorrect.
void __cdecl qSlicerSubjectHierarchyPluginLogic::onDisplayNodeModified(class vtkObject *,class vtkObject *) : Invalid object type calling display node modified event

And it looks like this:
image
instead of
image

What Slicer version did the correct rendering and which one failed? Does it work well if you downsample the volume? How the image changes if you move the shift slider? Do Advanced/Techniques/Quality settings make a difference?

This error is with the current stable. Last time I played with multi-volume rendering was in august, but I can’t remember the specific version it worked (it wasn’t with this dataset either).

As far as I can tell none of those settings make a difference.

Here is a link to the data (contains two nrrds)

Thank you for the sample images, I was able to reproduce the issue. The problem is that automatic sampling step computation does not work in the multivolume renderer, so the image spacing has to be approximately 1 to get good-quality rendering. The easiest is to edit spacing information in Volumes module (change the decimal point location). It would be great if you could enter a bug report for this so that we can investigate after VTK9 migration is completed.

Thank you. I am trying. But why is changing the location of decimal place is so hard in volumes? The field is trying to be smart at guessing what I am trying to do and failing miserably. For example, try shifting the decimal place one to the left in the origin tab of the MRHead. My behavior is to delete the decimal point and I can’t edit because the moment I delete that, Slicer adds a new decimal point at the end followed by 000.

I really find it frustrating that those field to do things automatically before I finish entering values.

I agree, it’s very annoying. The ctkDoubleSpinBox widget tries to be smart, but enforcing valid input during typing (after each keypress) is just so hard, probably in many cases it is not even feasible. See also this discussion. We should probably only validate values on Enter/leave.

1 Like