Fill Slice Views without Changing Image Spacing

Support
1

Hi,

I am using slicer to look at nondestructive testing data where volumes are typically sampled much more sparsely in the z (axial) direction than other directions (roughly 10 to 1). Additionally, the axial dimension is usually much larger than the other dimensions (i.e. we perform very long scans of components with a very tight imaging region). The volumes we are dealing with are like if we imaged at 10 cm x 10 cm square over the length of a human body in a CT scanner. I would like to be able to fill all slice view panes effectively changing the aspect ratio of the displayed image without changing the image spacing so that the measurements and slice positions read the correct positions. Commercial softwares for this type of applications routinely display the data with aspect ratios in each slice view which are not 1:1. Is this possible in slicer either by extension or python script or the like?

Any help with this would be greatly appreciated!

Thanks,

  • Jon
2

You can change the field of view in a slice view, for example enlarge it by a factor of 10x along one axis:

sliceNode = getNode('vtkMRMLSliceNodeYellow')
fov = sliceNode.GetFieldOfView()
sliceNode.SetFieldOfView(fov[0], fov[1]*10.0, fov[2])

This is not officially supported, so you might run into unexpected situations - mostly that the FOV is reset when you do certain operations (that you may address by adding an observer to the slice node and set the FOV back to your preferred FOV).

1 Like
3

Thank you so much! Works like a charm!

1 Like
4

Mr. Lassoan,

I am wondering if a similar set of commands can be used to set the field of view per axis on the volume view?

Many thanks,

  • Jon
5

In 3D view, changing the view’s aspect ratio would not make sense (as the view’s aspect ratio is fixed in display space and the object can be rotated around). To display a deformed volume in 3D, you can apply a transform to it (Transforms module) or change its spacing (Volumes module).

6

Hi Andras,

I have done as you’ve suggested in the past and of course I can distort the volume by changing the spacing or applying and transform, the issue is that the rulers and cursor positions do not read their true values afterwards which is critical for our industry. The volume view is not actually required so I can get by using the tips for changing the field of view in the slice panes.

Thanks!

  • Jon
7

It would not be hard to add an option to markups to report measurements in the node’s coordinate system instead of the World coordinate system but yours would be the first use case. If we hear from many other users that they would need this, too, then we can add it to the plan. If you need this sooner then you can implement it yourself or contract Kitware or others to develop it for you.

8

I’ve ran into this today. I’ve set the FOV to make the volume slice occupy the whole width of the sliceview. Can I prevent FOV resetting in some way? I’ve added the observer to revert back the FOV but there is sort of a flickering effect that is unpleasant to the users.
Thanks.

9

Check all the places that can change the FOV and propose designs that would allow preserving a custom aspect ratio. Keep everything backward compatible and aim for the minimum number of changes and number of impacted classes.

Was it necessary to apply changes/workarounds to make a custom aspect ratio in slice views work correctly?

10

Thanks for the directions. I will take a look at this.

The custom aspect ratio is working fine. We are even applying segmentation tools with it. It is funny that the paint tool looks like an ellipse when we distort the aspect ratio but I believe it is the expected behavior. I will report if I find any issues, so far so good.

11

That is exactly the correct behavior and probably what you want.

If you have the time and it is not confidential then it would be nice if you could show a few screenshots how it all looks and works.

1 Like
12

Hey Andras. I’ve recorded a quick demo of the current functionality we are working on. The video can be shared freely. I’ve used a screen cap from the internet as a volume, the real data is way larger on the SI direction. https://youtu.be/rBt-z9p9vVw
Except for the part I resize the layout the responsiveness is great. I may be calling too many times the FOV repair function, I will look into that to call it always some time after the last resize event.

The goal is to make a panel like this one below. But for now, we are doing an MVP on the segmentation of this kind of data https://erlend-viggen.no/dlis-files/

image
image800×1000 487 KB

13

Thanks for sharing, this looks great!

14

@lassoan, I’ve looked into the FOV resetting and found that the vtkMRMLSliceLogic is checking the aspect ratio of the window against the pane AR here

How do you feel about the following modification proposal?

  double windowAspect = (newWidth != 0. ? newHeight / newWidth : 1.);
  double planeAspect = (newFOV[0] != 0. ? newFOV[1] / newFOV[0] : 1.);
  double oldWindowAspect = (oldDimensions[0] != 0. ? oldDimensions[1] / oldDimensions[0] : 1.);
  double oldPlaneAspect = (oldFOV[0] != 0. ? oldFOV[1] / oldFOV[0] : 1.);
  if (windowAspect != planeAspect && oldWindowAspect == oldPlaneAspect)
    {
    newFOV[0] = (windowAspect != 0. ? newFOV[1] / windowAspect : newFOV[0]);
    }

This way the newFOV is corrected only if the user/dev did not change the aspect ratio of the slice view. If the aspect ratio is custom, there is no correction of the AR. While on a custom AR, if the user clicks center to volume on sliceviewcontroller, the AR returns to the original one.
I find it minimally invasive and it keeps the current behavior for the standard not distorted AR. If you think is a good idea I can open a PR for this.
This fix does not perform the behavior I want for the use case above, but the changes I need to apply to the FOV are less dramatic, improving the overall user experience.
Thank you very much.

15

If this is the only place where this causes problems then it should not be too hard to customize the behavior.

The window’s aspect ratio can change at any time and it would be hard to guarantee that the plane aspect ratio immediately follows it, so the check above might not be a robust solution.

Instead, what do you think about adding an experimental “AspectRatio” member to vtkMRMLSliceLogic, set to 1.0 by default. In the documentation of the get/set method it would be described that this is an experimental option only and only 1.0 value is tested. If you add sufficient amount of automatic testing that ensures that all important features work well with a non-default aspect ratio then we may consider making this a non-experimental, officially supported feature.

16

Ok thanks for the reply. I will consider working on your suggestion if I find any problems with the current one that I proposed.

One curious thing is that if the user sets the FOV via slice controller, the custom AR is kept when resizing the view. I did not look into how this is achieved.

17

It is not likely that we would integrate the change proposed above because it would introduce the risk of the aspect ratio of a view randomly changing. For example, if vtkMRMLSliceLogic::ResizeSliceNode is not called immediately after every slice resize (due to event compression, due to some views are being hidden, due to pausing the rendering, due to a change in how a view is created, etc.) then it could distort the view’s aspect ratio. It would also be important to let developers simply and reliably get/set the aspect ratio of a slice view anytime (even before a window has been created for it). In contrast, introducing an aspect ratio property to the logic is clean and simple, if it proves to be a solid solution and tests are added then it could be even made a property of the slice node.

18

Yes, I understand that my proposal is not ideal, but I will use it internally on our compiled version of slicer for now as it mitigates the issue I was having. As soon as I get the time, I will try to work on the suggestions you gave. I agree that they are better in all aspects. We always struggle with the share of time dedicated to the slicer base and the additional code we add to our client. There is always the feeling we are not contributing as much as we are getting help from the community. To be honest I am the only one messing with the slicer code. Next month a new project will kickoff and we will be adding 4 developers to the team, it should allow for more contributions to slicer :+1:
Thanks for all the help and I personally appreciate your incentives to try to make us work on the code base.

1 Like
19

Thanks for the information, this sounds great!

If you want, you can add the AspectRatio property to the slice node. That will probably make your implementation simpler.