Added angle of rotation (camera roll) for a 2D view.
Added the parameter KeepPlanePosition to restore plane position and orientation when Update( ) is called. The position and orientation of the axis will keep the same when a new data object is added to the rendering tree.
Description
Related Objects
- Mentioned Here
- T1684: Connect zooming of render windows
Event Timeline
Modified the default values of top and frontside to be backwards compatible.
Could you please explain me what's the purpose of this code?
mitk::SlicedGeometry3D::InitializePlanes( ):
bool flipped = (top == false); if ( frontside == false ) { flipped = !flipped; } if ( planeorientation == PlaneGeometry::Frontal ) { flipped = !flipped; }
I think this is related to 2d view management which is currently dealt with in T1684 .
(In reply to comment #2)
Created an attachment (id=443) [details]
Unified patchModified the default values of top and frontside to be backwards compatible.
Could you please explain me what's the purpose of this code?
mitk::SlicedGeometry3D::InitializePlanes( ):bool flipped = (top == false); if ( frontside == false ) { flipped = !flipped; } if ( planeorientation == PlaneGeometry::Frontal ) { flipped = !flipped; }
As far as I understand it, the "flipped" flag controls whether the 2D image "contained" in the SlicedGeometry3D is displayed face-up or face-down. This is affected by all three orientation properties (top, frontside, planeorientation).
For testing the patch that you sent, it would be very helpful to have an idea how to use it (e.g. from GUI). Do you have sample code that you could share with us here? Thanks!
Dear Mathias,
This could be a sample code to rotate 90 degrees a 2D QmitkRenderWindow:
void Rotate( QmitkRenderWindow *window )
{
mitk::SliceNavigationController::Pointer navigationController; navigationController = window->GetSliceNavigationController(); navigationController->SetAngleOfRotation( 90 ); navigationController->SetRotated( true ); navigationController->Update( );
}
To flip:
void Flip( QmitkRenderWindow *window )
{
mitk::SliceNavigationController::Pointer navigationController; navigationController = window->GetSliceNavigationController(); navigationController->SetFrontSide( true ); navigationController->Update( );
}
Best,
Xavi
Dear Xavier,
Thanks again for the patch, it's a really nice feature. I tested it in a small testing application and it worked fine.
However, I'd like to propose to implement the camera roll in a slightly different way.
In the current solution, the SlicedGeometry associated with the rendered scene is rotated directly when calling SliceNavigationController::SetAngleOfRotation(). As as result, a completely new resampling of the rendered 2D images takes place (due to the changed image geometry), which costs performance. Also, since the image resampling is done at angles non-orthogonal to the image matrix, some artifacts are introduced. You can observe this in the 3D view of the 2D planes; the texture of the plane slightly changes when the rotation angle changes.
As an alternative solution, the rotation could be implemented in the mitk::DisplayGeometry instead. In MITK, the DisplayGeometry is responsible for mapping actual image coordinates to display coordinates. This is currently only used for interactive panning and zooming of the image views, but it would be straightforward to extend this with a rotation parameter too.
The advantage of this approach would be increased performance, and no resampling artifacts due to world geometry modifications.
Note that very recently, the mitk::DisplayGeometry was extended to allow restriction of the panning area and zooming levels, so that the displayed image cannot leave the render window frame. This code would also need to be adapted if a rotation parameter was to be introduced in the DisplayGeometry class.
Please let us know if this feature would be of interest for you.
Dear Mathias,
Thank you for detailed explanation. I agree with your proposal. I think it's a better approach to implement camera roll than my approach. I tried to develop this feature in the way you propose, however, I found several problems, and finally I decided to develop the new functionality in the way I sent you. It will be a nice feature to change the implementation and use your approach.
Best,
Xavi
Dear Xavier,
Nice to hear. Yes, we will keep this feature request open for discussion. If we decide to implement it in the described or a similar way, you'll stay informed!
Best,
Mathias
Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.