BUG: Error when snapping electrodes to surface

[choldgraf]

Another bug popped up - after I sort the electrodes and run snap electrodes to surface, I get the following error:

  File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/pyface/ui/qt4/action/action_item.py", line 160, in _qt4_on_triggered
    self.controller.perform(action)
  File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/qt4/ui_base.py", line 138, in perform
    self.ui.do_undoable( self._perform, action )
  File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/ui.py", line 715, in do_undoable
    action( *args, **kw )
  File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/qt4/ui_base.py", line 158, in _perform
    method()
  File "gselu.py", line 1840, in do_snap
    self.model.snap_all()
  File "gselu.py", line 784, in snap_all
    subject=self.subject, max_steps=self.nr_steps)
  File "/home/knight/holdgraf/src/python/gselu/pipeline.py", line 1584, in snap_electrodes_to_surface
    hist,_ = np.histogram(neighbor_dists, bins=(max-min)/2, range=(min, max))
  File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/numpy/lib/function_base.py", line 249, in histogram
    n += np.bincount(indices, weights=tmp_w, minlength=bins).astype(ntype)
ValueError: operands could not be broadcast together with shapes (9,) (10,) (9,)

[aestrivex]

I need a bit more context for this, I haven't touched any of this code recently.

What do the grids look like?

On Thu, Dec 3, 2015 at 10:47 PM, Chris Holdgraf notifications@github.com wrote:

Another bug popped up - after I sort the electrodes and run snap electrodes to surface, I get the following error:

File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/pyface/ui/qt4/action/action_item.py", line 160, in _qt4_on_triggered self.controller.perform(action) File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/qt4/ui_base.py", line 138, in perform self.ui.do_undoable( self._perform, action ) File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/ui.py", line 715, in do_undoable action( _args, *_kw ) File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/qt4/ui_base.py", line 158, in _perform method() File "gselu.py", line 1840, in do_snap self.model.snap_all() File "gselu.py", line 784, in snap_all subject=self.subject, max_steps=self.nr_steps) File "/home/knight/holdgraf/src/python/gselu/pipeline.py", line 1584, in snap_electrodes_tosurface hist, = np.histogram(neighbor_dists, bins=(max-min)/2, range=(min, max)) File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/numpy/lib/function_base.py", line 249, in histogram n += np.bincount(indices, weights=tmp_w, minlength=bins).astype(ntype)ValueError: operands could not be broadcast together with shapes (9,) (10,) (9,)

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7.

[choldgraf]

In this case I believe it is 3 grids - two 2x8 grids and a 4x8 grid. I can send the MR/CT file if it's useful...

On Thu, Dec 3, 2015 at 8:18 PM, Roan LaPlante notifications@github.com wrote:

I need a bit more context for this, I haven't touched any of this code recently.

What do the grids look like?

On Thu, Dec 3, 2015 at 10:47 PM, Chris Holdgraf notifications@github.com wrote:

Another bug popped up - after I sort the electrodes and run snap electrodes to surface, I get the following error:

File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/pyface/ui/qt4/action/action_item.py", line 160, in _qt4_on_triggered self.controller.perform(action) File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/qt4/ui_base.py", line 138, in perform self.ui.do_undoable( self._perform, action ) File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/ui.py", line 715, in do_undoable action( _args, *_kw ) File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/qt4/ui_base.py", line 158, in _perform method() File "gselu.py", line 1840, in do_snap self.model.snap_all() File "gselu.py", line 784, in snap_all subject=self.subject, max_steps=self.nr_steps) File "/home/knight/holdgraf/src/python/gselu/pipeline.py", line 1584, in snap_electrodes_tosurface hist, = np.histogram(neighbor_dists, bins=(max-min)/2, range=(min, max)) File "/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/numpy/lib/function_base.py", line 249, in histogram n += np.bincount(indices, weights=tmp_w, minlength=bins).astype(ntype)ValueError: operands could not be broadcast together with shapes (9,) (10,) (9,)

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-161870496.

[aestrivex]

Sure, I'll take a look at it.

On Thu, Dec 3, 2015 at 11:52 PM, Chris Holdgraf notifications@github.com wrote:

In this case I believe it is 3 grids - two 2x8 grids and a 4x8 grid. I can send the MR/CT file if it's useful...

On Thu, Dec 3, 2015 at 8:18 PM, Roan LaPlante notifications@github.com wrote:

I need a bit more context for this, I haven't touched any of this code recently.

What do the grids look like?

On Thu, Dec 3, 2015 at 10:47 PM, Chris Holdgraf < notifications@github.com> wrote:

Another bug popped up - after I sort the electrodes and run snap electrodes to surface, I get the following error:

File

"/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/pyface/ui/qt4/action/action_item.py", line 160, in _qt4_on_triggered

self.controller.perform(action) File

"/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/qt4/ui_base.py", line 138, in perform

self.ui.do_undoable( self._perform, action ) File

"/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/ui.py", line 715, in do_undoable

action( _args, *_kw ) File

"/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/traitsui/qt4/ui_base.py", line 158, in _perform

method() File "gselu.py", line 1840, in do_snap self.model.snap_all() File "gselu.py", line 784, in snap_all subject=self.subject, max_steps=self.nr_steps) File "/home/knight/holdgraf/src/python/gselu/pipeline.py", line 1584, in snap_electrodes_tosurface hist, = np.histogram(neighbor_dists, bins=(max-min)/2, range=(min, max)) File

"/home/knight/holdgraf/anaconda/lib/python2.7/site-packages/numpy/lib/function_base.py", line 249, in histogram

n += np.bincount(indices, weights=tmp_w, minlength=bins).astype(ntype)ValueError: operands could not be broadcast together with shapes (9,) (10,) (9,)

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-161870496.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-161876574.

[aestrivex]

The snapping worked (it didn't quite get the configuration where it becomes more narrow on the first try).

I'm not sure quite where because the error handling probably isn't good but you are probably trying to give the snapping algorithm some kind of input that the program doesn't expect.

How are you trying to define the grids? The snapping procedure tries to snap all the electrodes that are assigned to subdural grids, and ignores electrodes assigned to depth electrodes or unsorted noise. If the grids are all assigned manually and you did not manually switch them from "depth" to "subdural" in the electrode window, none of the electrodes will be assigned to the snap group, and that would cause an error although this error message isn't quite like what I'd expect.

[choldgraf]

Hmmm, strange that it worked for you and not mine. My grid configuration was different - the main grid was cut in a few places, so I opted to fit 2 x 2x8 and one 4x8 grid instead of doing one 8x8 grid. Here's my plot:

https://www.dropbox.com/s/5706idlc9tvv4m0/gselu_plot.png?dl=0

On Fri, Dec 4, 2015 at 12:26 PM, Roan LaPlante notifications@github.com wrote:

http://imgur.com/1iawKoP

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-162072840.

[aestrivex]

It doesn't look like it's cut to me. I'd ask for surgical schematics, but looking at the CT it looks like there are several 8x2 strips (maybe the one in the middle is 8x4) which are partly overlapping.

The exact grid configuration doesn't matter for this purpose which is why I didn't bother precisely disambiguating the 8x2 strips. As long as they are all assigned to be subdural, what happens is that all of the subdural group electrodes are filtered separately as inputs to the snapping algorithm.

On Fri, Dec 4, 2015 at 3:45 PM, Chris Holdgraf notifications@github.com wrote:

Hmmm, strange that it worked for you and not mine. My grid configuration was different - the main grid was cut in a few places, so I opted to fit 2 x 2x8 and one 4x8 grid instead of doing one 8x8 grid. Here's my plot:

https://www.dropbox.com/s/5706idlc9tvv4m0/gselu_plot.png?dl=0

On Fri, Dec 4, 2015 at 12:26 PM, Roan LaPlante notifications@github.com wrote:

http://imgur.com/1iawKoP

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-162072840.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-162077563.

[choldgraf]

I assumed the strips were cut because of the surgical drawings that we got from the hospital. Either way, I guess I can just keep the grid as 8x8.

On Fri, Dec 4, 2015 at 12:57 PM, Roan LaPlante notifications@github.com wrote:

It doesn't look like it's cut to me. I'd ask for surgical schematics, but looking at the CT it looks like there are several 8x2 strips (maybe the one in the middle is 8x4) which are partly overlapping.

The exact grid configuration doesn't matter for this purpose which is why I didn't bother precisely disambiguating the 8x2 strips. As long as they are all assigned to be subdural, what happens is that all of the subdural group electrodes are filtered separately as inputs to the snapping algorithm.

On Fri, Dec 4, 2015 at 3:45 PM, Chris Holdgraf notifications@github.com wrote:

Hmmm, strange that it worked for you and not mine. My grid configuration was different - the main grid was cut in a few places, so I opted to fit 2 x 2x8 and one 4x8 grid instead of doing one 8x8 grid. Here's my plot:

https://www.dropbox.com/s/5706idlc9tvv4m0/gselu_plot.png?dl=0

On Fri, Dec 4, 2015 at 12:26 PM, Roan LaPlante <notifications@github.com

wrote:

http://imgur.com/1iawKoP

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-162072840.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-162077563.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-162080161.

[aestrivex]

I'd suggest to assign the grids as they are cut.

I simply didnt because it wasn't needed for testing this.

On Fri, Dec 4, 2015 at 4:11 PM, Chris Holdgraf notifications@github.com wrote:

I assumed the strips were cut because of the surgical drawings that we got from the hospital. Either way, I guess I can just keep the grid as 8x8.

On Fri, Dec 4, 2015 at 12:57 PM, Roan LaPlante notifications@github.com wrote:

It doesn't look like it's cut to me. I'd ask for surgical schematics, but looking at the CT it looks like there are several 8x2 strips (maybe the one in the middle is 8x4) which are partly overlapping.

The exact grid configuration doesn't matter for this purpose which is why I didn't bother precisely disambiguating the 8x2 strips. As long as they are all assigned to be subdural, what happens is that all of the subdural group electrodes are filtered separately as inputs to the snapping algorithm.

On Fri, Dec 4, 2015 at 3:45 PM, Chris Holdgraf <notifications@github.com

wrote:

Hmmm, strange that it worked for you and not mine. My grid configuration was different - the main grid was cut in a few places, so I opted to fit 2 x 2x8 and one 4x8 grid instead of doing one 8x8 grid. Here's my plot:

https://www.dropbox.com/s/5706idlc9tvv4m0/gselu_plot.png?dl=0

On Fri, Dec 4, 2015 at 12:26 PM, Roan LaPlante < notifications@github.com

wrote:

http://imgur.com/1iawKoP

— Reply to this email directly or view it on GitHub <https://github.com/aestrivex/gselu/issues/7#issuecomment-162072840 .

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-162077563.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-162080161.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-162082879.

[aestrivex]

Did you get this functionality to work?

[choldgraf]

No, I haven't been able to figure it out and needed to work on non-viz stuff for a while. Either way, it seems that many of snapping results put electrodes in places that don't make sense (e.g., a lot of my grids are near the Sylvian fissure and they will get placed on the inside of the fissure.), so it's possible I just won't snap electrodes to the surface anyway...

On Wed, Dec 9, 2015 at 11:46 AM, Roan LaPlante notifications@github.com wrote:

Did you get this functionality to work?

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-163370125.

[aestrivex]

I personally find that the snapping procedure is sometimes a bit funny, but that running it several times sometimes gives results that look more correct to the eye.

[choldgraf]

I think one problem is that the dural model seems to be incorrect. The shape looks good, but it is routinely offset by some amount. E.g.:

The smooth one is the dural surface. Looks to be correct except for the translation. Perhaps this is what throws off the snapping?

[aestrivex]

I've seen that bug before. I thought I had fixed it when I rewrote this to use pymcubes. I won't be able to get to it right away. On Dec 9, 2015 6:29 PM, "Chris Holdgraf" notifications@github.com wrote:

I think one problem is that the dural model seems to be incorrect. The shape looks good, but it is routinely offset by some amount. E.g.:

[image: image] https://cloud.githubusercontent.com/assets/1839645/11702154/263fb152-9e89-11e5-8485-dc97c8ca2ca7.png

The smooth one is the dural surface. Looks to be correct except for the translation. Perhaps this is what throws off the snapping?

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-163436031.

[choldgraf]

Ah ok...that probably is the issue then. It's not a freesurfer bug? If I generate lh.pial-outer-smoothed with the local gyrification index script, then the same problem is there.

On Wed, Dec 9, 2015 at 3:36 PM, Roan LaPlante notifications@github.com wrote:

I've seen that bug before. I thought I had fixed it when I rewrote this to use pymcubes. I won't be able to get to it right away. On Dec 9, 2015 6:29 PM, "Chris Holdgraf" notifications@github.com wrote:

I think one problem is that the dural model seems to be incorrect. The shape looks good, but it is routinely offset by some amount. E.g.:

[image: image] < https://cloud.githubusercontent.com/assets/1839645/11702154/263fb152-9e89-11e5-8485-dc97c8ca2ca7.png

The smooth one is the dural surface. Looks to be correct except for the translation. Perhaps this is what throws off the snapping?

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-163436031.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-163437582.

[aestrivex]

I think it is a freesurfer bug, my code just makes small changes.

I think I came up with a hacky workaround of some kind but I really don't remember what it was. It has been some time since I looked at this part. On Dec 9, 2015 6:40 PM, "Chris Holdgraf" notifications@github.com wrote:

Ah ok...that probably is the issue then. It's not a freesurfer bug? If I generate lh.pial-outer-smoothed with the local gyrification index script, then the same problem is there.

On Wed, Dec 9, 2015 at 3:36 PM, Roan LaPlante notifications@github.com wrote:

I've seen that bug before. I thought I had fixed it when I rewrote this to use pymcubes. I won't be able to get to it right away. On Dec 9, 2015 6:29 PM, "Chris Holdgraf" notifications@github.com wrote:

I think one problem is that the dural model seems to be incorrect. The shape looks good, but it is routinely offset by some amount. E.g.:

[image: image] <

https://cloud.githubusercontent.com/assets/1839645/11702154/263fb152-9e89-11e5-8485-dc97c8ca2ca7.png

The smooth one is the dural surface. Looks to be correct except for the translation. Perhaps this is what throws off the snapping?

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-163436031.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-163437582.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-163438234.

[choldgraf]

Hmm that's too bad. Maybe it's fixed in the beta version of the software.

[aestrivex]

I'll look at it again in a couple days and see if I can figure out what is going wrong

On Wed, Dec 9, 2015 at 8:27 PM, Chris Holdgraf notifications@github.com wrote:

Hmm that's too bad. Maybe it's fixed in the beta version of the software.

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-163457351.

[choldgraf]

I asked on the freesurfer listserv, and I was able to fix this by copying the header from the pial surface over to the smoothed pial surface. For some reason, the header information was changed...

[aestrivex]

I definitely remember having this problem but I'm having trouble reproducing the bug or figuring out what caused it in the first place.

Did you try to use the command mri_compute_lgi independently of the version gselu calls?

[choldgraf]

Ah, it is possible that it was using a version outside of gselu (I was playing around with the lgi function as well on my own). Let me try to reproduce and get back to you.

[choldgraf]

Hey - sorry it took so long to get back to you on this. When I've run into this problem, it's been with calling mri_compute_lgi manually through the command line, not through GSELU. I'm not sure what you mean by "independently of the version calls"...you mean the Freesurfer version?

Either way, I looked through the GSELU code and it seems that you just implemented what "mri_compute_lgi" does in python, is that right?

I spoke with some folks on the Freesurfer listserv and it seems that the problem may be related to headers being incorrectly copied over. Does that ring any bells for you?

Hope the New Year is treating you well! On Mon, Dec 21, 2015 at 1:41 PM, Roan LaPlante notifications@github.com wrote:

I definitely remember having this problem but I'm having trouble reproducing the bug or figuring out what caused it in the first place.

Did you try to use the command mri_compute_lgi independently of the version calls?

— Reply to this email directly or view it on GitHub https://github.com/aestrivex/gselu/issues/7#issuecomment-166432156.