Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MRview: Odd behaviour on the opening of ROI's #296

Closed
rodneyanderson opened this issue Jul 18, 2015 · 23 comments
Closed

MRview: Odd behaviour on the opening of ROI's #296

rodneyanderson opened this issue Jul 18, 2015 · 23 comments
Assignees

Comments

@rodneyanderson
Copy link

When opening any ROI an odd shape appears. However it disappears on slicing through the image (or on striking any key!). It doesn't seem to impact on any other processes. (The ROI's in the images attached are DWI masks. The same ROI opened in two different sessions)

I am using:
OS X Yosemite 10.10.4

Qt version 5.4.1

== mrview 0.3.12-546-g0d01cd28 ==
64 bit release version, built Jul 14 2015, using GSL 1.16

mrview: [INFO] GL renderer: NVIDIA GeForce GT 750M OpenGL Engine
mrview: [INFO] GL version: 4.1 NVIDIA-10.4.2 310.41.35f01
mrview: [INFO] GL vendor: NVIDIA Corporation

screen shot 2015-07-18 at 14 36 14

screen shot 2015-07-18 at 14 42 13

@Lestropie
Copy link
Member

Suspect this is the same problem as #293... not quite sure how we're going to deal with this one... Also strange for it to have suddenly cropped up out of nowhere.

@rodneyanderson
Copy link
Author

I hadn't done a git pull for a couple of months (I can't really remember when) as I was running some big datasets. So I only noticed it when I updated recently. Not much of a help diagnosing when it happened, sorry!

@Lestropie
Copy link
Member

There's not really a whole lot you can provide; it just has to do with the way we load texture data only when it's actually needed, rather than pre-loading everything. Though it is interesting that it started after an MRtrix update rather than a QT one...

@rodneyanderson
Copy link
Author

After battling to sort out Qt problems (two versions and a host of other hassles) a while ago, I am now loath to mess with Qt!

@jdtournier
Copy link
Member

@Lestropie, I initially thought the same thing as you (that this might be related to #293), but in this case the texture upload is fine, it's just its initial render that's messed up. I'm assuming in #293 the ROIs aren't usable at all...? But there's every chance that it's the same underlying cause: the OpenGL context for the paint event that triggered the upload gets messed up by another paint event before it has a chance to complete. Presumably the update prevention approach we were discussing in #295 would sort this out?

jdtournier added a commit that referenced this issue Jul 20, 2015
As discussed in #293, #295, #296 & #298. This essentially ensures the
ProgressBar display only kicks in after 1s (so will only affect things
for large loads); that the main window does not try to process further
updates in the meantime; that mouse events to the main window are not
processed until completion; and that the GL context is preserved only if
one in found.

This works as expected on Qt4. On Qt5, for some reason the background of
the main window is cleared to default (grey) as soon as the progressbar
is displayed. I'm hoping this is a glitch in Qt5.5 - I can't see any
reason for them to clear the background of a widget that explicitly has
updates disabled...
@jdtournier
Copy link
Member

please try with the latest commit on master (a8a7202), see if that fixes it...

@rodneyanderson
Copy link
Author

Didn't seem to sorry Donald.

@jdtournier jdtournier self-assigned this Jul 21, 2015
@jdtournier jdtournier added this to the MRtrix3 3.0 release for ISMRM milestone Jul 21, 2015
@jdtournier
Copy link
Member

Darn. Ok, assuming this was related to an MRtrix3 update rather than an OS, Qt or OpenGL driver update, the one major change that had happened recently that might relate to this is the move from the deprecated QGLWidget to the new QOpenGLWidget. I'll have a go at this later today on my MacOSX relic, see if I can reproduce. The chances are however that it would be fixed by upgrading Qt to 5.5... Note that having got rid of conflicting versions of Qt, you should now be able to run multiple versions of Qt side by side - the versions provided by the company install in non-default, non-conflicting locations, it'll just use whichever version you manually set in your PATH. All you'd need to do is install the new version next to the previous one, modify your PATH to point to this new version, run ./configure, and ./build - I did that recently, no problem.

Another change was to set MRtrix to request a core OpenGL profile by default on all platforms, but that was already the default on MacOSX (can't get OpenGL 3.3 otherwise). I notice that MRView is reporting a 4.1 profile, which is unexpected - I was expecting to get a strict 3.3 profile. Can you check whether you have the NeedOpenGLCoreProfile: 1 set in your ~/.mrtrix.conf config file? Try setting it to zero see if that makes any difference... I don't think it'll help one bit, but you never know.

@jdtournier
Copy link
Member

OK, confirmed on my mac too. I'll have a look...

@jdtournier
Copy link
Member

This is going to be a tough one - things work fine under Linux, also on nvidia hardware. Debug build runs clean on valgrind, no OpenGL errors detected, no bounds check failures...

I'll try to checkout earlier versions, see if I can pinpoint what changes introduced the problem...

@jdtournier
Copy link
Member

OK, it was indeed pull request #266 (i.e. the move to QOpenGLWidget) that introduced the problem. I'm not sure how to proceed, since things to work OK otherwise, it's just the initial render that's corrupt. I'll have a close look at how the ROI tool handles its render, maybe there's an obvious way around this...

jdtournier added a commit that referenced this issue Jul 21, 2015
@jdtournier
Copy link
Member

OK, turned out to be simpler than I'd anticipated - just a matter of making sure the GL context was current when loading/saving/modifying the ROI textures. See if commit 08f47ef fixes it for you - seems to work fine on my mac...

As a bonus, you also get correct handling of scrolling with the touchpad, and pinch to zoom... 😄 I'll add support for the other gestures at some point, but it'll require a fair bit of refactoring of the event handling.

@rodneyanderson
Copy link
Author

Excellent! All good Donald, works fine on my mac now.

Thanks for the bonus :) Only been on macs for a few years now (PC's for the last 20years!) but must admit I love all the gestures!

@rodneyanderson
Copy link
Author

Actually, there is a bigger problem now. When creating a new ROI or editing a current ROI the odd render comes up on initial edit and remains there! It doesn't disappear on slicing. I can't really edit or create new ROI's.

screen shot 2015-07-22 at 07 39 43

@jdtournier
Copy link
Member

I guess it never rains but it pours... I'll have a look into that one tomorrow. Can I just check: that used to work fine before this latest set of changes, right?

@rodneyanderson
Copy link
Author

Yes I was using it for the whole day yesterday and it worked fine. This morning with the latest commit it doesn't.

Cheers!

@jdtournier
Copy link
Member

Sure, a simple git reset --hard HEAD~1, then ./build should do the trick. That'll get you back to before the changes to the ROI tool, but you get to keep the improved touchpad handling - hopefully that's got nothing to do with this problem...

@rodneyanderson
Copy link
Author

Thank you Donald...I just wound back my time machine on the mrtrix3 folder...but I might use your method so I get to keep the improved touchpad handling.

@Lestropie
Copy link
Member

I have the same issue now on Linux. The ROI seems to initially load OK, but initiating a ROI edit on mouse click fills the slice with unwanted data. Curiously, the contents that the slice gets erroneously filled with repeats itself every 8 clicks...

jdtournier added a commit that referenced this issue Jul 22, 2015
@jdtournier
Copy link
Member

Right, after a very extensive OpenGL debugging session, I eventually tracked down the source of the bug. It was embarrassingly trivial - see how extensive commit 47578e7 is...

I also fixed a few more things along the way. See if the current version on master works for you...

@rodneyanderson
Copy link
Author

That seems to have done the trick Donald! All works well on the mac.

Yes a few little bugs with the ROI editing tool also seem to have been ironed out as well.

@jdtournier
Copy link
Member

Good to hear - now I can get on with my life... I'll close this off then. Feel free to reopen if needed.

By the way, if you come across other bugs, do report them, however minor. We may not fix them immediately, but at least we'll be aware of them...

@rodneyanderson
Copy link
Author

Cheers Donald!

I was a little reticent about posting such a minor issue, but will certainly in the future.

Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants