As this picture shows, the ROI is a cube, and sometimes it may be better to change it to a sphere. Of course, this function PRISM rendering can be implemented, but it will be more convenient if you can directly adjust the ROI. Or is there a corresponding script code to achieve.The other is whether it can make the image of the ROI content disappear, and the image outside the ROI can be displayed
It’s not real-time like the ROI, but you can get install the Segment Editor Extra Effects and then use the Mask Volume to make arbitrary shapes.
Thanks for your reply, Doctor , I would like to know if I can change the ROI to a sphere, I think this setting should be easier, but I don’t know how to adjust the script
Currently, you can simulate sphere ROI by interacting with markups points or rectangular ROI (see example script here). You can use PRISM (or create a custom module with a streamlined GUI for making things simpler for the users) to clip with that ROI.
In a few weeks we will have sphere ROI (you can monitor status of this here), which solves the first part of the problem. I am not sure if non-rectangular ROIs will be supported by volume rendering module or you will need an external module, because there are just so many special cuts and effects that you can imagine that we cannot add everything the volume rendering module directly. Probably we’ll make PRISM module more user friendly instead.
What is your use case? How do you plan to use spherical clipping? Is there any additional volume rendering effects (special coloring, highlighting, etc.) that you would ideally would like to use?
Dear professor, do you consider replacing the ROI in Volume Rendering with the sphere tool in PRISM rendering? I believe this is a favorite of many users. Because sometimes we need to simulate the skull window. Of course I know that mask volume or Clip volume with ROI can be used, but that is complicated,and that is the real cut, not hiding, sometimes we just need to hide part of it.
In the long term, probably we will need custom volume rendering methods for each rendering use case. These specialized methods will have more inputs than just a volume and ROI (for example they may take additional points, lines, volumes, segmentations, sliders, checkboxes, combo boxes, etc.) and many of the parameters that are currently shown in Volume rendering module will not be necessary to modify.
To get there, the current plan is to:
- keep Volume rendering module more or less as is
- use PRISM module to allow specification and testing of advanced volume rendering methods
- create custom modules for each major rendering scenario with a simple user interface, which exposes all the necessary options and only those. For example we could have separate modules for 4D cardiac echo, 4D endovascular CT, brain MRI surgical planning, brain MRI real-time surgical guidance. These would be simple and small Python scripted modules that could be easily cloned and customized easily for new applications. These modules can be small because they are all just thin wrappers around features provided by other lower-level modules.
We already have such a custom volume rendering module for 4D cardiac echo, which we will refine and can use as a template for other modules. Until these specialized modules come out, you can use PRISM directly (any suggestions are welcome about how to make it more convenient) or you can implement your own custom module that allows users to choose input nodes and parameters and sets up volume rendering accordingly.
1 Like
So it means “Do not change at all”, right?
Changes will be driven by fulfilling needs of specific applications. Right now, it does not look like that changes in the Volume rendering module will be required, because we want to offer very high flexibility for module developers to customize the volume rendering experience, which a C++ module is less suitable for. Trying to address all volume visualization needs by improving a Volume rendering module is not realistic anyway, because optimal visualization often includes preprocessing, combination with models, markups, etc. and we would not want volume rendering module to be intertwined with so many other modules.
As specialized volume rendering modules will be developed, time to time we will review what is common between them and if make sense then move commonly needed features into Volume rendering module. So, some Volume rendering module changes and improvements are expected, but these probably will not be very visible to users.