Mrview crash when running with VirtualGL

Dear experts,

I am experiencing crash of mrview if using mrview with VirtualGL, i.e. running vglrun -c proxy mrview on remote VNC session when I attempt to threshold my tractogram according to the .tsf file (p-value). My aim is to visualize streamline segments corresponding to fixels with significant effect, as suggested in

https://mrtrix.readthedocs.io/en/latest/fixel_based_analysis/displaying_results_with_streamlines.html

My mrview version:

3.0_RC4-71-gb26d8555

The terminal output is:


mrview: [ERROR] GLSL log [fragment shader]: 0(11) : error C1020: invalid operands to ">"

mrview: [ERROR] error compiling OpenGL fragment shader ID 16

When viewing volumes, or tracks (without using .tsf files) the vglrun -c proxy mrview works OK. This error also does not appear when running mrview directly on local machine.

Is here anything I could do to remedy this and retain a possibility to use mrview via VirtualGL?

Antonin

It looks like this bug, which was fixed and merged to master in November 2019. But I think you’re using the dev branch? There’s no 3.0_RC4 tag on master… We’ve not ported all the bug fixes on master back to dev for a while now, maybe we should do that soon. In the meantime, it’s a one-line fix, feel free to apply the fix directly to your installation (just edit the file as per the diff above, save, then type ./build).

Thank you, this fix indeed helped!

However, looking at the rendering with lines and thresholding according to .tsf, strange thing happens: There seem some artificial points visible outside relevant thresholded track segments, changing their visibility when zooming the image:


Not visible with pseudotubes:

I am testing this with the most recent master branch.

Antonin

I have to admit, I’m not sure why there would be such a discrepancy, other than if these dots correspond to isolated vertices that are supra-thresholds, but the adjacent vertices are not. In this case, it’s possible that rendering with GL_LINES (which is what happens with ‘Lines’ rendering) at least renders the point that makes it above threshold, while rendering GL_TRIANGLE_STRIP (which is what’s effectively used when rendering with pseudotubes) doesn’t produce anything if only 2 vertices are present out of the expected 4.

You could try rendering with ‘points’, and check whether the additional dots are still there – I expect / hope they will, that would explain what you’re seeing.

As to whether there’s any way to make the two equivalent, I’m not sure we can do that very easily. It would require some additional GPU geometry shader magic, and a considerable coding effort…

In fact, using “points” most of the dots disappear (see cursor):
Pseudotubes:


Lines:

Points:

Looking at the source fixel thresholded by fwe_pvalue.mif, there is no displayed fixel visible at the cursor.
It seems like a bug with thresholding when rendering with lines? But never mind, I could switch to pseudotubes…

Playing with this, I was wondering whether
a) is it possible to somehow inspect value of tsf on cursor? Probably not very easily…

b) how could I obtain fixel value(s) at particular spatial coordinate? Some command line fiddling could do the trick?

Antonin

P.S. screenshots in this post also illustrate my recently posted feature request

I’ve never seen anything like that myself either. Could you possibly upload the background image / track file / TSF so that myself or Donald can try to reproduce? Also, are the erroneous points when displaying with lines specific to running through VirtualGL, and are they specific to a certain dataset?