Errors on basic co-registrations

[choldgraf]

Hey there - this looks like a useful tool. I've been trying to get it to work with some of the MRI/CT files we've got in the lab, but I'm having a hard time making it through the pipeline without running into errors. In particular, right now I get the following error after the pipeline runs for a few minutes:

  File "gselu.py", line 1653, in _run_pipeline_button_fired
    self.model.run_pipeline()
  File "gselu.py", line 426, in run_pipeline
    aff = self.acquire_affine()
  File "gselu.py", line 335, in acquire_affine
    zf_override=self.zoom_factor_override)
  File "/home/knight/holdgraf/src/gselu/pipeline.py", line 1335, in register_ct_using_zoom_correction
    print 'resampling image with zoom_factor %.2f'%zoom_factor
TypeError: float argument required, not TraitListObject

Not sure if that's useful, but I'm not familiar with the code at all so it's tough to debug on my end right now. Maybe once I get more acquainted with it. Either way, wanted to give you a heads up now in case it's a bug.

[choldgraf]

I was able to get around this issue by switching the co-registration mode to uncorrected MI registration rather than experimentalshapecorrection. However, now it's throwing another error saying that it can't find the file mri/transforms/ct2mr.lta. Note that all the files in my freesurfer subject folder are only the ones that are generated by default with recon-all. Maybe there is something extra I needed to do?

[aestrivex]

Is there no such directory as mri/transforms in the Freesurfer subject dir? gselu tries to write the affine transformation to SUBJECTS_DIR / SUBJECT / mri / transforms.

In version 5.3 of Freesurfer this directory is created by default in recon-all. But maybe it is doesn't get created at all in a different version.

[aestrivex]

If that does not solve the problem, and you want to continue debugging it yourself faster than I can respond, the relevant function (used by the "uncorrected MI registration" option) is in pipeline.py, https://github.com/aestrivex/gselu/blob/master/pipeline.py#L1071

[choldgraf]

Hmm ok cool, I will play around with this a little bit and get back to you. I believe that this is being done on the latest version of freesurfer, and I do think that the mri/transforms folder exists (maybe just not that file). Either way I'll dig into it a little bit more. Thanks for the help!

On Mon, Nov 23, 2015 at 7:02 AM, Roan LaPlante notifications@github.com wrote:

If that does not solve the problem, and you want to continue debugging it yourself faster than I can respond, the relevant function (used by the "uncorrected MI registration" option) is in pipeline.py, https://github.com/aestrivex/gselu/blob/master/pipeline.py#L1071

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

[aestrivex]

There was a small ongoing bug which caused the first error with the experimental shape correction option. I think this should be fixed now (but this option should be only necessary if your CTs have incorrect headers, as described https://github.com/aestrivex/gselu/wiki#fixing-skewed-registrations).

I still dont understand the other error, its supposed to create the file ct2mr.lta in mri/transforms

[choldgraf]

OK, I got the pipeline working w/o any errors. The problem was on my end, there was an incorrect path to the FS subject folder. By just running it on the Freesurfer MR and the raw CT, there are some weird results. For example, here's what popped out of the pipeline:

That looks...strange. Are all those red points electrodes? Maybe the CT slice information is incorrect?

I should mention, I'm doing this reconstruction on a relatively sub-par ecog subject. There is a ton of variability in the quality of CTs and MRs that we get, so I'm trying this on something that's probably a bit noisier than normal in order to figure out how robust it is.

[aestrivex]

Yes the red dots are supposed to be electrodes (that is, possible electrode locations, we expect to see some noise too).

I see a lot of variability also in the CTs that I get from my collaborators also and so I spend a lot of effort in writing some code to deal with bad images, including images that have bad headers. It's rare -- although has happened -- that there is just no way at all to deal with a bad CT. Unfortunately dealing with bad CTs is often difficult and requires a bit of experience. (this section covers most of it but manual inspection is required https://github.com/aestrivex/gselu/wiki#fixing-skewed-registrations)

It looks to me at first glance that you have the same problem, that the CT header is not faithfully reporting its slice thickness (and also the slice thickness of the CT is very high).

Would it be possible to send me the CT you are using? I will try to document what steps I take to fix it.

[choldgraf]

I can do that - email is fine? The same one you replied with originally on the neuroimaging listserv?

[aestrivex]

Yes

[choldgraf]

wow, that was fast ;)