Connectome node mesh visualisation problem

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

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

Screenshot%20from%202018-04-30%2014-47-38

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:
locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE=“en_US.UTF-8”
LC_NUMERIC=hr_HR.UTF-8
LC_TIME=“en_US.UTF-8”
LC_COLLATE=“en_US.UTF-8”
LC_MONETARY=hr_HR.UTF-8
LC_MESSAGES=“en_US.UTF-8”
LC_PAPER=hr_HR.UTF-8
LC_NAME=hr_HR.UTF-8
LC_ADDRESS=hr_HR.UTF-8
LC_TELEPHONE=hr_HR.UTF-8
LC_MEASUREMENT=hr_HR.UTF-8
LC_IDENTIFICATION=hr_HR.UTF-8
LC_ALL=

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

LANG=“de_DE.UTF-8”
LC_COLLATE=“de_DE.UTF-8”
LC_CTYPE=“de_DE.UTF-8”
LC_MESSAGES=“de_DE.UTF-8”
LC_MONETARY=“de_DE.UTF-8”
LC_NUMERIC=“de_DE.UTF-8”
LC_TIME=“de_DE.UTF-8”
LC_ALL=

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.

2 Likes

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!
Cheers,
Marlene.

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.

Darn, that’s not what I wanted to hear… It looks like the issue might not be specific to ATI after all, then. Although it could be a result of the uninitialised variable issue I pointed out in this post. Is there any chance you could modify the code as suggested in that post, see if that deals with that particular issue? If so, that’s an unrelated issue with an easy fix. Otherwise, it’ll take a lot of effort to debug that one…

Hi,
I’ve been following this post for a while because I have the exact same problem: Streamline visualization works, streamtube visualization does not (no edges show up). Since it’s been a while since the last update, I was wondering whether you could solve the problem by now?

Best,
Marlene.

@jdtournier, I’m sorry I didn’t reply sooner, we’ve been very busy in the Lab and I didn’t have access to the macOS until today.

I’ve done a checkout of the last version available in the GitHub repository (as far as I’ve seen, that version includes the patch in the post you pointed out). I’ve tried the visualization again with this new version and the problem is still there. Streamlines work fine but streamtubes are missing.

Also, the visualization with cylinders works fine, so if the OpenGL primitive used for cylinders is the same as for the streamtubes, could it might be a problem in the generation of the streamtubes instead of OpenGL?

Also, the visualization with cylinders works fine

That’s a useful little piece of information; I’m not sure if it will get me anywhere, since the cylinder and streamtube renderings follow significantly different code paths, but it at least gives me something to go on.

Ultimately reproducing any error is the first step in diagnosing it, which is why I’m so powerless here… Maybe if someone encountering the issue could provide me with ssh access to their machine and activate a video call with screen sharing so I can perform debugging on their system remotely? :sweat_smile:

Same here, cylinders, streamlines and the parcellated meshes work, just the streamtubes don’t –as mentioned here: Visualising edges as streamlines / streamtubes .
Rob, if you want, you can access my laptop, no problem at all. Our timezones might be conflicting a bit though (Berlin / Europe)…