Modify vector plot to display SH peaks and eigenvectors

[Lestropie]

So... basically... a more... 'generalized' orientation overlay? :-P

[draffelt]

Not unless you care to implement it. However it would be very simple to modify the current vector plot to load peaks.

Personally I can't see too many other users needing to visualise dixels. Tensors could be handled in a separate tool if you really want to display them.

I think flicking between separate ODF/Vector/Tensor tools using tabs is cleaner than having a single list of overlays with a separate popup toolbox associated with each item type.

[Lestropie]

Yeah, I think getting the generalized version to work (at least the way it is in my head) kind of relies on being able to change the contents of the tab, i.e. you have the file list and anything common between all overlays at the top of the tool bar, and the lower half of the same tool bar changes its contents to reflect the options available for the particular overlay currently selected.

But if, as you say, that actually can't be done with QT, then it may not be the cleanest option.

One extra option that will be needed for reading in XYZ vectors is a check box to flick between vectors being defined in real v.s. image space (i.e. FSL).

[draffelt]

You might be able to modify the contents of the current pane in QT, might be worth looking into. I recall looking into it when creating the track scalar tool, however maybe we went with the popup for other reasons (I can't recall sorry).

[jdtournier]

As far as I recall, the popup was mostly to prevent cluttering up the display needlessly when most people would rarely (if ever) use that particular functionality in the tractography tool... No issue with doing what you're talking about with Qt otherwise, it was purely a UI design decision.

Otherwise, I think adding support to read 'normal' vector images is the right way forward - it's simple and leverages existing code. The generalised orientation overlay idea sounds really complicated to get right and maintain... I'd personally rather have more tools that each do a specific job well, than a few one-size-fits-all tools that will probably end up being really messy to get right UI-wise. In this case, given our current definition of 'fixel', I think it makes sense that this tool would also be used to display orientations from a vector image.

[Lestropie]

I don't see that the generalized approach should be too much more complicated. One way of thinking about it is that we could generate individual tabs for ODF plotting, vector / fixel plotting, dixel plotting, tensor plotting... at some point, half of the available tool tabs would be regarding overlay of orientation information, which are never going to be used in parallel. So you make a new tab that handles plotting any kind of orientation information. The ideas in my head were essentially jumping to that final point. But there's no reason why such tools can't be developed independently and we can then consider a combination process later.

For instance, just incorporating loading XYZ direction images using the existing fixel overlay tool (even though these are the most similar overlay types) is going to cause UI issues; the fixel overlay has options (e.g. 'colour by') that are invalid for purely XYZ data. So you end up with options in the UI that either don't work or have to be disabled for certain input images.

[draffelt]

SH peaks and EV images have an amplitude and therefore the colour/length by value options will still be relevant.

If the user has a unit vector image for some reason, then I'm ok with it rendering with the max colour bar value.

[Lestropie]

You could take the norm of each vector at read time before normalising the vectors and use that to allow length by amplitude & colour by amplitude, but it's not strictly equivalent to the 'colour by value' we currently have. You could redundantly write this amplitude into the metric value associated with each fixel, but then you have two options that behave identically to one another (e.g. with the current UI options, 'line length by value' will do nothing).

I'm not trying to shoot the whole idea down, go for it absolutely. I'm trying to highlight how you're going to run into the kind of issues that my generalized orientation overlay, where only options relevant for the particular file currently loaded are displayed, is intended to solve.

[draffelt]

My plan was to do exactly that. Load the normalised vectors into the directions GPU buffer, and the norm of the vectors (i.e. the peak AFD or eigenvalues) into the value buffer. I don't quite understand why this is an issue? Colour/threshold/length by value will work exactly as it does for Fixel images.

[Lestropie]

It's not an 'issue', it's just redundant. E.g. length by amplitude & length by value will be one and the same. Thresholds will apply to fixel amplitudes where they would normally be applied to associated metric values (i.e. the amplitude is the value). What I mean is, if fixel images didn't exist and you were designing a overlay tool from scratch for XYZ images, some of those options wouldn't exist or would be designed slightly differently. So there's more scope for user confusion.

I agree it's not worth the effort of having a separate tool bar to distinguish between fixel and XYZ input images as there's so much overlap in functionality; that's not what I'm arguing for. The point is that depending on the type of orientation information that you're looking at, some functionalities are common, and some are not.

[draffelt]

Sorry I didn't click that you were talking about both the amplitude and value members of the FixelMetric class in the display.

Not sure if you have played around with it yet, but currently the Vector Plot tool only uses the value field in the FixelMetric class. This is for both colouring and length.

Personally I think it's cleaner if the viewer supports only a single scalar in the FixelMetric class. As I said in my recent Gitlab comment, if you want to view multiple scalars then you can always load up multiple images and flick between them.

[Lestropie]

OK, I'd looked at the tool itself but hadn't played. I had intended at some point to add options so that you could scale length by unary (i.e. all fixed length) / amplitude / value, colour by direction / amplitude / value, and threshold by amplitude / value. From the very get-go I made sure to include the amplitude in the FixelMetric class so that it would be included in all output images, precisely for this purpose.

[jdtournier]

OK, just a couple of things:

• I don't see how the generalised orientation overlay tool can possibly not be massively more complicated to use and maintain. In a previous version of a previous version of a precursor to MRView (MRV, for those who've come across it), I had something akin to this, which was able to display either SH plots, or plots derived from the DWI at runtime (tensors, SH fit to DWI, SD of DWI, etc). There weren't that many options, but keeping track of what to display when and what needs to be recomputed when a certain button is pressed, etc. was a total mess. I'm keen to avoid a sequel.
• Why wouldn't I want to display vector plots and SH plots simultaneously? Would be a good way to see how far off my DT eigenvectors were, verify by SH peaks are correct, see how my AFD results line up with the WM geometry, etc. If everything was handled by the one tool, I'm guessing this wouldn't be possible.

[Lestropie]

• I'd imagine a lot of that complexity would have come from the fact that you were using runtime calculations. If anything I'd think a generalized tool would be easier in that respect: if something is done that requires an update of any orientation overlay, and there's currently an overlay active, re-draw the overlay for whichever one file is currently selected. If an option relating to orientation overlay is changed, only those options valid for the currently-active overlay are actually shown to the user, so you know that the overlay needs to be updated. If you have multiple tools for different overlays, then you would have to check each one in succession.
• I see that as a comparatively rare use case; and because they'd all be part of the one tool, you'd be able to flick back and forth between them with a single button press, just like you can currently between fixel images.

[jdtournier]

OK, I think we're not going to reach a consensus here...

I think the best course of action right now is for Dave to add the option of loading non-sparse direction data, since it should be pretty quick & straightforward and will already give us all the functionality we need. In the meantime, the issue Rob opened for the generalised orientation overlay is still there, so we can carry on the discussion over there if need be.

[Lestropie]

Yeah. Displaying the non-sparse direction data using the fixel tool is fine by me for now. And realistically if I want to try the generalized tool down the track, it's going to be borrowing existing back-end code anyways.

Regarding the amplitude field, removing it at this point is going to cause more heartache than leaving it there; and we all agree that storage space is not an issue. So I'd rather it be left as-is rather than going through all that then demonstrating later that it's actually of use.

[rtabbara]

The Vector plot tool should now be able to open non-msf files.

• The open file dialog allows you to select to filter between MRtrix sparse or Medical Images.
• In the latter case, there's some sanity checking in place when opening to ensure that the image selected indeed is a vector image.
• As mentioned in the discussion, a consequence of gelling with the layout of FixelMetric means that for non-spare images, the choice of scaling by 'Fixel Size' or 'Associated value' will both coincide with the norm of the vector.