BUG: Error when snapping electrodes to surface about ielu

[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 [email protected]
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_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,)

—
Reply to this email directly or view it on GitHub
#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 [email protected]
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 [email protected]
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_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,)

—
Reply to this email directly or view it on GitHub
#7.

—
Reply to this email directly or view it on GitHub
#7 (comment).

[aestrivex]

Sure, I'll take a look at it.

On Thu, Dec 3, 2015 at 11:52 PM, Chris Holdgraf [email protected]
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 [email protected]
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 <
[email protected]>
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_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,)

—
Reply to this email directly or view it on GitHub
#7.

—
Reply to this email directly or view it on GitHub
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

[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 [email protected]
wrote:

http://imgur.com/1iawKoP

—
Reply to this email directly or view it on GitHub
#7 (comment).

[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 [email protected]
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 [email protected]
wrote:

http://imgur.com/1iawKoP

—
Reply to this email directly or view it on GitHub
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

[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 [email protected]
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 [email protected]
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 <[email protected]

wrote:

http://imgur.com/1iawKoP

—
Reply to this email directly or view it on GitHub
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

[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 [email protected]
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 [email protected]
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 <[email protected]

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 <
[email protected]

wrote:

http://imgur.com/1iawKoP

—
Reply to this email directly or view it on GitHub
<#7 (comment)
.

—
Reply to this email directly or view it on GitHub
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

[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 [email protected]
wrote:

Did you get this functionality to work?

—
Reply to this email directly or view it on GitHub
#7 (comment).

[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" [email protected] 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
#7 (comment).

[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 [email protected]
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" [email protected] 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
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

[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" [email protected] 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 [email protected]
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" [email protected]
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
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

[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 [email protected]
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
#7 (comment).

[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 [email protected]
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
#7 (comment).