Connectome node mesh visualisation problem

For some reason, I’ve been able to run mrview without problems using the “Start debugging” option in the Qt Creator GUI. I’ve tried running the same binary from bash with and without gdb and I can’t view the meshes in those cases.

Also, running in debug mode from Qt Creator allows me to load streamtubes.

I’m not sure what is happening there. If you have any suggestion on what to try or check, please tell me.

I’m stumped. I just checked this on my Arch Linux setup, and my Win10 MSYS2 laptop, everything works as expected. But given the issues raised in this thread, there’s a suggestion of a funny interaction with Qt5 that might be causing issues. Maybe you could try removing the Qt5 development packages, installing the Qt4 equivalent packages, then running ./configure and ./build again, and see if that fixes the issue?

Otherwise, I’ve no idea how the same binary executed within the Qt debugger could possibly behave differently outside of it. But it does suggest a potential memory issue, I’ll have a look into that next week if I find the time…

Hi @martahedl,

I’m not sure a debug build is necessarily going to help if the software doesn’t crash outright. I wouldn’t bother, just keep using the version you’ve already installed (through homebrew, presumably?). It seems there are issues somewhere in the OpenGL handling, given that similar issues are being reported on other systems. This is not something you’ll be able to fix or even investigate very easily. Unfortunately I’m not in a position to replicate the issue, but I’ll give it a shot next week if I find the time…


After some debugging, we’ve reached the conclusion that it seems to be a problem with the LC_NUMERIC locale. We have our systems configured in Spanish, where “,” is the decimal separator. This can be causing the
sscanf (data.c_str(), “%f %f %f %f”, &values[0], &values[1], &values[2], &values[3]);
reads wrong positions.

If we include something like this

import <locale.h>

setlocale(LC_NUMERIC, “C”);

in the MeshMulti::load function, meshes work fine.

I’m not sure if that can be the related to what is happening with streamtubes.


EDIT: “locale.h” was wrong. It should be <locale.h> because the previous had a compilation error.


I have installed mrtirx through macports instead of homebrew. I guess that makes no difference? Unfortunately, Alberto’s suggestion to change the MeshMulti::load function doesn’t do the trick for me. Would you need the data I’ve been using to replicate the issue?


Wow, great work! That can’t have been easy to track down…

This sounds similar to this issue that @bjeurissen encountered a while back. The added problem there was that this was internal to Qt, which meant we couldn’t modify the code – there was nothing we could do other than modify the locale, in pretty much the same way as you suggest.

However, in this instance, we do have control of the relevant code. @rsmith, I suggest we change the problematic line from what it is now:

sscanf (data.c_str(), "%f %f %f %f", &values[0], &values[1], &values[2], &values[3]);

to something that relies on our own string converters, which somehow ignore the locale, like:

auto list = split (data);
for (int n = 0; n < 4; ++n)
  values[n] = to<float>(list[n]);

What do you think? There might be other places in the code to modify similarly…

Also worth moving this discussion off to GitHub at this point.

Not really, but it will affect the exact procedure and the specific flags that might need to be set in the configure call. So it helps to know if we’re trying to help you to compile a debug build. You should be able to use the exact same steps as you must have used to compile your original installation, but with -assert -debug at the end of the ./configure line – everything else should be the same…

I think we’ll need to take a look at the data to get to the bottom of this. But before we do, it might be worth looking into whether you might not have the reverse issue: maybe the numbers are written in the file using the comma as the decimal separator, and your locale is set to use a dot? Can you look at the file in a text editor and see how the numbers are stored? It should be just text…

OK, so here are the first few lines of my .obj file:

# mrtrix_version: 3.0_RC2-37-gb4bca32f
o none
o 1
v -31.120390560477745 -56.278932370245329 -16.580981446196731 1.0
v -31.620390579104196 -55.778932373970619 -16.580981401260416 1.0
v -31.120390597730648 -55.778932400047651 -17.080981490667384 1.0

OK, that doesn’t seem to be the issue. Feel free to send me the problematic file, by email or any other means:, I’ll take a look when I have a minute.

I just loaded your mesh file, everything seems fine on my system:


I’ll try it with a debug build, see if that throws up anything…

Hi mrtrix experts!

I have encountered the same problem.

For me, when i do label2mesh and mesh filter. None of the files produces any node.
I have tried to build mrtrix with various versions of Qt, including two qt4 and two qt5 versions with no difference.
I even did start debugging with Qt Creator GUI, but nothing.

Here is my openGL information and picture that i get.

@martahedl: Could you try locally modifying the code according to @jdtournier’s suggestion? If this is a more general issue around text-string conversions in different locales, it might require a decent block of changes to MRtrix3, which will take a bit of work, so I’d like to know beforehand whether or not such a modification actually fixes the issue. @david142: You could try the same modification if you’d like.

Also, if anyone encountering the issue could provide the output of the locale command, that might help to determine whether or not we’re going down the right rabbit-hole.

More technical details on GitHub.

Thank you for your brief answer!

I tried to modify the code according to @jdtournier 's suggestion, but it did not help :confused:

Output of the locale command:

Same for me. Here’s the output of my locale:


That’s strange. LC_NUMERIC for de_DE uses “,” as decimal separator (I’m not sure in the case of hr_HR).

In case it helps, the steps I made for solving the issue in three different Ubuntu/Debian machines were the following:

First, change the code in MeshMulti::load (src/surface/mesh_multi.cpp) replacing the line
sscanf (data.c_str(), “%f %f %f %f”, &values[0], &values[1], &values[2], &values[3]);
with @jdtournier’s sugggestion:

auto list = split (data);
for (int n = 0; n < 4; ++n)
values[n] = to(list[n]);

Finally, recompile mrview with ./build bin/mrview

Also maybe you can try to change LC_NUMERIC to en_US.utf8 in your system. I tried that and also does the trick for me.


Thanks so much, Alberto. It was changing the LC_NUMERIC that finally did the trick for me:

Very cool :sunglasses:

Thanks again to you all, guys!

Thanks all, that’s great to hear. We’ll make the necessary changes upstream - see the GitHub issue for details.

And thanks again for all your efforts to figure this out, I appreciate this stuff takes time!

Alberto one extra thanks from me. Simply changing LC_NUMERIC to en_US.utf8 worked :slight_smile:

Thanks a bunch!

@albertofpena, any chance you could confirm whether the locale handling changes discussed here (and now implemented in the latest 3.0_RC3 release) also fix the streamtubes rendering issue you initially reported? We have reports from other macOS users that this isn’t working, and we’re trying to figure out whether this might be related to the use of an ATI graphics card. If you also still have the issue, we’ll know it’s not that simple (assuming you’re using a Nvidia system, which your previous screenshot suggests).

Streamtubes are working properly now in my Linux machine. I’ve tried in a macOS machine and I can view meshes but I can’t see streamtubes (streamlines work fine.) The installation on the macOS machine was done via Homebrew, so I’m afraid it’s not running the last version with the fix. Here I’m attaching a screenshot of the OpenGL info window:

As that one is not my computer I’m not sure I’ll be able to tinker and install last MRtrix version there, but if I see anything else I’ll let you know.