MRView: remove single ODF display from ODF tool?

[jdtournier]

I'm starting to wonder whether we need the little display of the ODF in the tool itself. When using it recently, I've always gone straight for the overlay... Does anyone think this is still useful? I rarely use it, and if I genuinely did want to inspect my ODFs close up, there's nothing to stop me zooming in anyway...

The reason I ask is because it does take up a lot of space, and we could simplify the ODF tool significantly by simply getting rid of it. It's also historically been a bit of a pain having two OpenGL viewports - used to cause glitches with older drivers, although I guess this is probably no longer relevant. It also messes with the delayed update of the main window, although we did implement a workaround.

If we did this, we could make the tool look more like the current overlay, tractography, and ROI tools, which would make the interface a little bit more consistent.

[bjeurissen]

I am in favor of leaving it out.

[dchristiaens]

I do think it comes in handy from time to time, especially for quickly inspecting high-res datasets, but most often I jump to the overlay as well... I guess I'm undecided :)

[draffelt]

I never use it. Now that you can overlay off axis, you can always zoom in and rotate. I've lost minutes of precious life clicking that overlay check box, and changing the wrong 'detail' input box

On Thu, Mar 26, 2015 at 11:53 PM, Daan Christiaens <notifications@github.com

wrote:

I do think it comes in handy from time to time, especially for quickly inspecting high-res datasets, but most often I jump to the overlay as well... I guess I'm undecided :)

— Reply to this email directly or view it on GitHub https://github.com/jdtournier/mrtrix3/issues/194#issuecomment-86501165.

[Lestropie]

I find it useful every now and then, usually assessing the results of FOD segmentation. We could definitely decrease its default size. And possibly have the overlay default to on.

I am also in favour of keeping it because I want to have the same thing once I implement a dixel overlay. These will have a lot more fine detail per voxel, so being able to examine one voxel data more closely will be useful. Then, I still like the idea of having a somewhat consistent interface for all of the orientation overlay tools, which would sensibly include a close-up view of voxel data.

[jdtournier]

Man, I was hoping for a consensus...

@Lestropie - OK, not sure we can shrink the ODF panel a great deal, it's already not that big. Besides, it saves us nothing in terms of reducing the amount of bloat in the code, avoiding issues with multiple OpenGL viewports, or cleaning up the UI on the ODF tool to help @draffelt hit the right button...

I'm not sure exactly what you have in mind for the dixel overlay (is it what you describe in #11 ?), but until it's implemented, I'm not sure we should make decisions about the ODF tool on that basis. What's important is that the tool meets our needs and those of our users, and that it gets in the way as little as possible most of the time. And we do have to prioritise for general use cases in the community rather than our own - this was never intended to remain in-house...

On that basis, I think getting rid of the close-up panel makes sense. The default action most people will want to perform most of the time is a full-blown overlay. There is nothing stopping anyone from zooming in to a specific voxel to have a closer look, or using the scale control to make it bigger, etc. And there is no restriction of the viewing angle either. So I don't see that removing the close-up panel leads to any loss in functionality...

Does this sound OK to you? Maybe we could just try it out on a separate branch and see how people feel about it...?

[Lestropie]

Yeah, it's one of the things that would fit into #11. Theory was that the panel would work for any type of overlay (ODF, dixels, fixels, tensors, ...), potentially with more graphical information than the overlay (e.g. show eigenvectors of the tensor)

If I were to put on my user hat and didn't know anything about OpenGL implementation, I wouldn't be happy about losing it. Turning off axis locking on the main image window just to arbitrarily rotate one ODF would feel like a work-around; rotation would be much slower, and you'd be forever fiddling to try to get the focus right at the middle of your voxel of interest so it doesn't wobble around as you rotate. And you can only zoom in on a voxel to see its details so far before overlays from adjacent voxels get in the way.

[jdtournier]

Not sure I agree - well, pretty sure I don't...

As a user, most people really want the overlay first and foremost. Having it as the default and only option probably reduces the amount of thinking you need to do to use the tool, particularly for new users. And I really don't think you'd lose anything in terms of functionality.

Just to test this out for myself, I had a go at using it to inspect a particular ODF. Personally, I found it to be pretty easy. With the overlay box ticked, load the data in the tool, zoom in to the region you want to look at (no need to scale the ODF itself, that would indeed cause overlap), and start rotating directly (no need to use the lock button, we made it unlock automatically on rotate a while back). I found it pretty quick and intuitive to use, at least on my system - remember that rendering an off-axis slice is essentially as quick as it is when on-axis - they're both implemented using 3D texturing, the only slow-down is the initial upload of that volume's data onto the GPU, which is pretty quick in most cases. The ODF render itself is much more onerous. It's true that rotating when rendering a large number of ODFs is slow, but once you zoom in, only the ODFs within the viewport are rendered - it's dead quick. And there was no particular issue with the focus not being dead centred onto the ODF of interest - yes, there was some wobble, but it didn't really bother me particularly...

I realise this is probably not the most objective test, so it would be good if others could give it a shot and report back...

[thijsdhollander]

So can't we cater to everyone's needs by basically doing this:

1) remove the "ODF display thingy" from the ODF display panel (I also feel it's very far from my default use case, and it pushes down the overlay controls way to the bottom of the panel for no good reason) 2) put the load/close buttons and the list at the top of the panel 3) directly underneath the overlay checkbox (defaulting to "on") + its detail setting, lock to grid checkbox, grid setting, and the lmax setting 4) underneath that goes the lighting checkbox, colour by direction checkbox, hide negative lobes checkbox, and possibly interpolation checkbox (which in this case would essentially switch between linear interpolation (on) and nearest neighbour (off), but for the actual overlay; for fixels and other doesn't-want-to-be-interpolated-stuff in the future, it could be disabled so only nearest neighbour is available) 5) ... and all the way at the bottom of the panel, a tiny obscure button labeled "investigate ODFs" or "ODF magnifier" or any other fancy name. When pressed, it opens the ODF view tool "thingy" in a separate panel that might by default not even be docked to the main window.

This fixes the default use case, gets the little tool out of the way, but it's still available for whoever fancies using it. While using the main view for investigating a single ODF works ok-ish, using @jdtournier 's description above, I must admit that:

1) the wobble behaves funnier than I expected. Even when the focus is perfectly in the centre of the ODF in question, still it hobbles all around my main view in a less than intuitive manner, and does some decent mileage as well. I'm almost feeling a tad nauseated after I just did that a bit too enthusiastic. 2) there's this use case where I want to investigate the ODFs in a well defined region (for arguments sake, say the midsagittal plane through the CC or something), but at a certain specific orientation (say I want them to be left-right-lobed, so I get a good view on potential small negative lobe artefacts). Now I can simply go to the view in question (sagittal), rotate the ODF preview thing to the orientation I need (left-right-lobed), and then click/drag away through the CC to view all ODFs up close in the orientation that I need. I know, it seems like a weird use case, but I do find myself doing it at times while investigating typical crossing regions (rotating the preview so the crossing plane is parallel to the screen). In these cases, it helps greatly in appreciating the relative lobe sizes (they are very deceptive at any other angle).

So yeah, I agree with most of the things already said previously; but I think an elegant middle ground should be possible.

[jdtournier]

You should take a look at pull request #219 - I've had a go at doing this, you can see for yourself what it would look like.

I do agree however that the wobble is worse than I was hoping. There's a combination of issues at play here, which might be worth thinking about to see if we can come up with a better solution.

The first issue is the way rotations are applied. At the moment, the centre of rotation is the centre of the viewport (target in the code). This means that rotations behave sensibly when the crosshairs are not visible, and also in-plane rotations behave sensibly with respect to the user's mouse movements. However, we also need to ensure the focus remains in-plane, and this is where all this wobbling comes in. Every rotation is actually a rotation and a translation to bring the focus back into the viewing plane.

The other issue for the ODF tool in particular is that the focus (crosshairs) is a 3D position, and will not in general lie centred on the imaging plane - if you think about it, there's no sane way to do this when viewing a tilted slice. This is not a problem when viewing a regular image with interpolation turned on (and the axis lock off), but here we're trying to display the ODFs on a regular grid. We're trying to ensure the ODFs are centred on their voxel when conditions allow (i.e. the viewing plane is aligned with the ODF image's axes, and the grid is set using an image with identical properties) - there's no way we can ensure this when the axes don't match. The way this is handled right now is by setting the grid according to a central 'pivot', determined using the centre of the voxel nearest to the centre of the viewport (i.e. the target, again). The grid is then set using the voxel sizes of the image selected in the 'grid' widget along the viewport's axes (actually, a function of them to provide reasonable values when off axis, but which reduces to the voxel sizes when on-axis). This works fine for the default case - rendering ODFs atop their original data, with no tilt.

So if you put these two together, you can see that this centre voxel can change as the view is rotated, which means the ODF you were looking at might also change... This happens when the focus (crosshairs) its sufficiently far away from the target that rotations shift the target into a different voxel, causing the grid to lock onto a different pivot. Even if it doesn't, this will cause some wobble unless the target and focus are well aligned, which is actually not easy to do on the UI...

I think the simplest way to fix this is to genuinely rotate about the focus. I might mock this up when I have a minute, see what it feels like - unless anyone else feels like helping out...? I'm a bit swamped at the moment with this gimormous code refactoring that some people have been asking for...

[jdtournier]

By the way, I do like the idea of a separate popup window for close-up inspection. For now though, I think I'll probably concentrate on making the main overlay work well, I reckon that would fulfil most users' needs (and mine). If anyone has the time and energy to implement the popup window, feel free. Otherwise, we can always add it in at a later stage.

[jdtournier]

closing - use pull request #219 to carry on the discussion...