I’m a beginner in developing Qt/VTK applications using C++, and I don’t have much knowledge in VTK yet. I’m trying to set up a panoramic view by drawing a curve through the axial slices, selecting a reference slice from a DICOM directory. Using this drawn curve, I need to generate a panoramic view considering all slices.
In the panoramic view, I want to set up a reslice cursor to select and update the slice over that region.
When I click on these regions, I need to update the 3D positions of the plane widgets for both the axial and sagittal views. The sagittal plane widget should be adjustable, allowing the length to be modified, and the slice view should be updated (length of planewidget(only for sagittal) which will adjust the plane widget’s length and increase the length of the slice view using the slider in sliceviewer). In the axial view, I want to show a small line over the curve to indicate the position of the sagittal plane widget [Image 1]. Along with that, I want to set up multislice(consecutive slices) if needed.
For example, the Curved Planar Reformat module provides invertible transform between the original CBCT and straightened space. This allows you to place implants in the panoramic image and get their position and orientation in the CBCT.
Slicer also provides fully automatic AI dental segmentations on CBCT, registration between intraoral scans and CBCT and much much more. I would recommend building any dental imaging application on 3D Slicer instead of just raw VTK. Slicer is built on VTK, just adds a lot of higher-level features, and it is all free, restriction-free, open- source - the same way as VTK.
Thank you Andras Lasso for reply. But I need to make as an independent application. I don’t which classes are been used for getting sagittal slice view from the panoramic view and get reflect slice viewer positions in 3D(as planes), axial and panoramic view(reslicecursors) in VTK…
Slicer is already an independent application that you can customize and extend any way you need.
You can create a new application from scratch, redevelop or copy-paste features from Slicer. It makes sense as a learning experience. However, the resulting software will be probably much less capable, robust, and flexible, and you need to invest several years of development time instead of a few months. This is important because if you need to spend less time with redeveloping features that are already freely available elsewhere, you can work on things that matter, that are unique, that set your application apart, or fine-tune the user experience so that clinicians love what you implement.
There is ongoing work to add GPU-based CPR in VTK (https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10766), but it still requires some effort to complete the integration. Another approach could be to use vtkImageReslice which can handle any types of transform.
GPU-based CPR is great. Does the GPU acceleration do a CPR transform specifically or it can apply any VTK grid transform?
Application of any grid transform would be really useful, because a two-way transform mapping between original and straightened space is needed for more complex use cases, that reuire showing 3D plans, devices, etc. in the straightened space; transferring annotations from the straightened space to the original space. If the exact same vtk(Oriented)GridTransform can be used by the volume renderer and by polydata transform filters then all the requirements of complex use cases can be fulfilled.
Thank you for your insight, we should definitely consider every use cases before going further with this implementation.
In its current state it does a CPR transform specifically (here). This could be extended to support any kind of transform I guess, @Thibault_Bruyere can confirm.
Yes, this implementation is quite flexible. It overrides the sampling of 3D textures in the fragment shader, and apply the custom3DTransform that Lucas linked. In the case of the CPR, this function transforms the coordinates using the centerline information, but we could replace the custom3DTransform with anything, including a VTK grid transform.
This sounds very promising. Implementing CPR as a special case of grid transform could worth the extra effort. For example, it could be used to render CT images acquired with variable slice spacing or tilted-gantry.
FWIW we are also working on another approach for GPU-based CPR, something like vtkProbeFilter but running on the GPU. An additional surface can be passed to the mapper to project the original surface used for probing. It means you can use a curved plane to probe the 3D volume, and project the results on a straightened plane. We still need funding to complete the integration in VTK, but first results look promising:
This does not address the transform requirements mentioned above though, which should be taken into account to complete the ongoing work with the CPR volume mapper.
