[andreashorn]

Hi Luke,

as a general rule of thumb, always ignore warnings in lead-dbs (this is just a warning, not an error).
The result files should already be there.

Best, Andy

[andreashorn]

Hi Monique,

no, we implemented a 0-polynomial version of PaCER. For curved leads, I’d recommend to try the PaCER standalone. It’s not really planned to implement support for curved leads since this would also result in a lot of adaptions to our VTA model and microelectrode recording tool, etc. We feel that for most applications (if interest is only on the contacts), a straight model is a good approximation. Of course, curved leads could be interesting if the trajectory itself is of interest (but can be easily calculated using PaCER standalone.

Hope this helps,
Andy

[andreashorn]

Hi Kurt,

the rpostop_ct.nii needs to be resliced to the anat_*.nii files for it to work.
You can do so by calling

ea_conformspaceto(‘anat_t1.nii’,’rpostop_ct.nii’)
but please note this changes/overwrites the rpostop_ct, so better make a copy of it.

After that make sure images are still co-registered (e.g. with SPM).

then it should work.

Best, Andy

[andreashorn]

Hi Robert,

Lead DBS (non-group normal mode) supports multiple leads since the recent release (with limitations). But if it’s just for visualization, this should work. You’d need to switch the “3” and “4” togglebuttons on and localize them again (or manually merge the two ea_reconstruction files in your separate folders in Matlab).

That should make it possible to look at them in native space.

As you probably know, lead group only works in MNI space (given it’s designed for group analyses).

Hope this helps!

Best, Andy

[andreashorn]

Hi Robert,

you’d need a preop scan (call them anat_t1.nii and anat_t2.nii) and at least one postoperative MRI (postop_tra.nii) – call that one tra even if it’s sagittal. If you have multiple postop scans, you can call them postop_tra.nii, postop_cor.nii and postop_sag.nii

Now if you don’t have any baseline preop scan it’s hard to do it (given the lead artifacts will have a nonlinear impact on the normalization step). What you can do is to use the Linear Three-step protocol (but do make sure to read the associated schönecker paper so that you understand what really happens there).

If you want to try that, you’d make a duplicate of the single postop scan and call one copy postop_tra.nii, the other copy anat_t*.nii

best, Andy

[andreashorn]

Hi canbe,

the .ply files are in MNI space.
You’d need to convert the coordinates to native space e.g. using ea_map_coords (but it involves some programming in Matlab).

Finally, visualizing VTAs – you’d need to convert the .nii files exported by Lead-DBS to surfaces – e.g. using isosurface() – and also export these as .PLY. These are in MNI space, though, too.

It’s all a bit involved and does require programming custom code + good knowledge about coordinate systems of nifti files and nonlinear warps.

If you prefer the 3D Slicer Render Engine over Matlab, one alternative idea could also to do the whole processing in Slicer instead of Lead-DBS? I know that the pyDBS software developed in Rennes / Paris is able to run inside 3D Slicer.

Hope this helps!

Best, Andy

[andreashorn]

Great!

[andreashorn]

Hi Nik,

seems your Matlab doesn’t have write permissions to the current Matlab directory. Just change to somewhere else and re-run. Should work then.
If this doesn’t work it could be the myaa function somehow doesn’t work on your system. You could try to replace line 404 in ea_writeplanes with
saveas(gcf,[options.root,options.patientname,filesep,options.elspec.contactnames{el},’_axial’,isofnadd,’.png’]);

and try if this works. But this would export figures in lower resolution.

Best, Andy

[andreashorn]

Hi Nik,

sure, the contacts are stored in ea_reconstruction.mat -> reco.mni.coords_mm (for template space) and reco.native.coords_mm (for native space).
You can easily define a point in space and e.g. calculate distance with the pdist function of Matlab.

Best, Andy

[andreashorn]

Hi Mevlüt,

re the other models, please refer to their papers to better understand what they do.
Re our VTA model (which is still in beta version), it does matter which atlas you use to define the grey matter. Please also refer to the paper for specific questions first.
Some atlases lead to intersecting vertices in the meshing part and are thus not suited to define grey matter. The DISTAL Minimal atlas should work in most cases and gives a very precise definition of the grey matter of question – but of course this only works if the regions are the ones you’re interested in (they are STN, GP & RN).

Best, Andy

[andreashorn]

Hi nhaliasos,

there seems to be something off in this – likely due to SPM version compatibility. We’ll check and let you know.
In the meantime, maybe try normalization with ANTs (SyN low variance + subcortical refine protocol)?
This seems to be the best protocol currently implemented in Lead-DBS (at least for STN and GPi).

Best, Andy

[andreashorn]

Great, glad that it works!

Best, Andy

[andreashorn]

To write out 2D results you mean?
The step that takes long is the ea_screenshot function which uses myaa (antialiasing) code to write out high resolution figures. Could in theory bypass that and use a simple saveas() command if the slow speed bugs you too much. Guess it also depends on the atlas. Does 3D visualization work and did you check reconstruction in the intermediate step?

Best, Andy

[andreashorn]

Hi Nabin,

maybe first step is to change the entrypoint to “Manual” and click on the leads when asked.
https://leaddbs.gitbooks.io/leaddbs-manual/content/Reconstruction%20of%20Electrode%20Trajectory.html

Best, Andy

[andreashorn]

Great, thanks for letting us know that it worked!

Best, Andy

[Author]

Posts