I’ve run into similar issues before due to misinterpreting meaning vtkImageData bounds. It all comes down to how you define “bounds” for a VTK data set. It makes things much simpler if bounds are computed as the box that contains all data points. It is very easy to compute this, it works for all data sets (polygonal and volumetric meshes, point sets, etc), and this is the definition that is used throughout VTK. However, developers often don’t know or forget that vtkImageData extends 0.5 voxel beyond its “bounds” (so
GetBounds() output is not the same as the image’s physical bounds), which can lead to seemingly incorrect or inconsistent behavior. Sometimes these can be considered to be bugs, but often you can justify and document the current behavior instead of changing the behavior that so many current software depend on.
I’ve tested with your data set and it seems that all renderers use VTK bounds for rendering (not the physical bounds). Since this has been like this forever (and extrapolating the image might be complicated and/or computationally intensive), I don’t think that this will be changed. You can address this by adding a single-voxel boundary (e.g., repeating the border voxels or setting to some uniform value). Considering these, behavior of the 3 raycast mappers in VTK:
- GPU volume raycast mapper works consistently with all settings.
- CPU volume raycast mapper’s nearest neighbor interpolation’s behavior is quite surprising (does not make sense to me) and I would consider it as a bug. You can report this to the VTK bugtracker, but since the mapper’s development stopped about 10-15 years ago and probably not many people care about rendering with nearest neighbor “interpolation”, probably if you need a fix then you would need to implement it yourself.
- GPU multivolume raycast mapper indeed computes one side of the bounds incorrectly (it is asymmetric and inconsistent with all other mappers). This mapper is still a work in progress. It has many (more serious) issues. So, it makes sense to report this so that when VTK developers take care of the other issues then they fix this one, too. Submit the sample data set as a mha or non-compressed nrrd image instead of DICOM so that VTK developers can use it more easily.