best strategy for drawing on vtkImagePlaneWidget

I would like to draw pixel ROIs on a volume visualized with vtkImagePlaneWidget using the built in cursor. Currently I have set up 2 vtkImagePlaneWidgets, one for the image and one for the ROI. The ROI widget simply follows the Image widget and renders the selected pixels. It is rendered slightly above the Image widget so the pixels are seen above it - see picture.
This works ok, but I wonder if there is a better way to render on top of a vtkImagePlaneWidget? Should I be thinking about polygons on top of the plane or something else perhaps?


(I’ve edited my answer as I realized I misinterpreted the question previously)

One option is to blend the slice extracted from the CT and the same slice extracted from the segmentation labelmap into an RGB image and display that in the renderer.

Note that this kind of visualization has been implemented many times. There are dozens VTK-based, free, open-source medical image visualization applications; several of them are extensible frameworks that you can customize for your particular use case. Therefore, I would recommend to not spend time redevelop everything from scratch, but build your application on an existing application framework, such as 3D Slicer or MITK.

Hi Andras,
Thanks for your reply! That may work - so I guess the ImagePlaneWidget would show and RGB image and I would handle the window-levelling myself.
I have looked at Slicer 3D and I understand there is a lot of useful functionality implemented.
My need is typically to run custom GUIs on a set of cases in a folder structure. So it’s typically patient centric GUIs, where an ID is selected and multiple components are read for that patient. It’s also important to me that the time from making code changes to running the code and accessing my datasets in the GUI is as short as possible.
Do you think I will save time by using Slicer 3D under these circumstances?
If so which component in Slicer 3D which you use to achieve what I am looking for?
I have looked at Slicer previously, but I found it more involved than reading the documentation for VTK classes.

This is a very common use case for 3D Slicer. Typically you use the default (complex, but powerful) Slicer module user interfaces to figure out your complete workflow. Once you know exactly what and how to do, you can create a small Python scripted module that automates most of the steps and provides a simplified user interface.

This is very well supported. You can make changes to your running code, and then with a single click of the reload button, your module is updated to the latest version. No need to restart the application or reload any data.

Yes, you’ll save a lot of time. You may need to spend a few weeks learning how to use Slicer, but you’ll get many features that but would have taken you years to develop. Just by using Slicer you’ll also get access to the Slicer community - the Slicer forum with 6000+ members, training and development events, etc. The next Slicer Project Week is coming up in about a month, which is a great opportunity to start developing your custom module or solve some challenging problems, with help from Slicer experts and community members.

You can display “pixel ROIs” in Slicer using the segmentation module. This is a good starting page for it. If you have any questions about Slicer, I would recommend to post it on the Slicer forum.

1 Like

Like @lassoan I’m a long-time Slicer developer, so I’m biased, but I’ll definitely echo his suggestion that Slicer is a great environment to do VTK development. Especially if you are just writing a pure VTK python script, the ability to reload the code and refine the Qt gui while the data is still in memory can be very productive. Slicer also provides an incredible amount of infrastructure if you are doing any kind of applications involving dicom, interactive annotations, segmentation, linear/nonlinear transforms, etc. These are not easy things to get right, even if you know what you are doing. Yes, it’s a large dependency and that may turn people off, but for a lot of us that’s a fair tradeoff considering what you get in return.

If people have different experiences or opinions let us know - we are always looking to improve the ecosystem or learn what works for other people.

1 Like

Thank you @lassoan and @pieper! You have a compelling case and it seems it will be worth the time investment. Deployment etc with collaborators will be easier too which is also a important to me.
Thanks for the pointers and advice!

1 Like