03/18/2016 at 5:16 AM #840
I was wondering if Lead-DBS automatically detects bilateral or single electrode cases.
Now I’m testing on my own ct data with single electrode trajectory. Normalization worked well. I always got an error in reconstruction. It seems like the reconstruction is being processed on the both side although the data has electrode trajectories only on the right side, and this resulted in the error with message “Mask out of bounds. Must have lost trajectory”.
v1.4.2 on the manual has an option to check LH or RH, but it was disappeared on v1.4.8. So, I assumed that v1.4.8 may automatically detect it.
Finally, can users get final output files (as nii or stl format) to visualize in another viewer (e.g., slicer or fsl)?
I would appreciate your answers.
Gene03/18/2016 at 2:44 PM #842
unfortunately, for now, unilateral leads are not really supported (and they were, you’re right).
You wouldn’t think so, but especially in the lead_group analyses, including unilateral lead cases just makes the whole implementation a lot more complex.
If it’s just for visualization, what you can do, however, is to set the entrypoint in the main lead GUI to “Manual” and just put two leads into the same artifact by clicking on it for both hemispheres. In the 3D visualization viewer, you can then just deselect one of the leads.
If you’re a little bit into programming, you can also set a breakpoint at the beginning of ea_autocoord.m (which is the main trigger function following the button press of “Run”) and set options.sides to either 1 (right lead only) or 2 (left lead only). In the normal case, this value is set to [1,2]. This would trigger the functions as in the old version and should still work for most of the one-subject-only functions (even though I can’t guarantee it).
We will re-introduce the unilateral case support again in the future, just need to find the time to do so..
To export final output for visualization in other software: Atlases are present as .nii files. VATs are now generated as .nii files, as well. The electrodes can be exported to a JSON string which is similar to .stl format by pressing the cloud button (“Export to server”) in the 3D viewer. They are not uploaded to any real server or similar, it’s just that you can make results web-viewable e.g. for an intranet server that you set up for your hospital.
I can also provide you a script that will export the tips of the electrodes as nifti files, if you want. This is being done for headmodel generation in the novel VAT model code. You’d need to send me your email address or similar.
Hope this helps,
Best, Andy03/19/2016 at 2:54 PM #849
Thank you for quick response and clarification.
I’ll try to do tips you mentioned.
Gene06/28/2016 at 9:51 PM #1177
I read about the script for exporting electrode tips as nifti files. This would be very useful for me – and I like to ask if you please would share.
Uppsala University, Sweden
firstname.lastname@example.org/28/2016 at 11:33 PM #1178
Mailed you. Will add some more export features in the near future.08/31/2016 at 4:15 PM #1421
First of all, I experienced some difficulties getting the .m file to work, actually I can seem to get any exported files at all – the folder headmodel is not created either. Though I’m getting the option to do the simulation after pressing the wand button – vat files in nifti format is produced during simulation but these files are just black. Is there any options or procedures that needs to be done before?
And I also have some general questions regarding lead-dbs.
I have been thinking about the scenario using post-op CT, however not as common at my institution but performed anyway from time to time.
Sometimes when manually defining the electrode artifact during reconstruction the images is just black – perhaps its because some pre-processing step is incomplete, I think this phenomena only occur when i skip registration and normalization – just change the postop_ct to lpostop_ct.
Usually I ask our neurosurgeon to manually delineate target structure so the only step i need to take is to register them. But I believe that the black scene appears then as well.
Second question. So preferably we do postop MRIs – including a 3D_T1 image and T2w, PD or T2-STIR depending on target. The 3D_T1 is always included and covers the whole brain and cause no problem regarding SAR/B1+rms levels. However, Medtronics updated guidelines give a little bit more space to increase the coverage of the T2w image for example, but not near the T1. But back to the question, do you have any experience segmenting the electrode based on T1w image? I tried it and it seems to work, but having trouble checking cause I don’t get the nifti, of course there should be other ways of confirming but I’m prefer this until I found something better.
And have I understood it correctly that the normalization step is only for getting structures from template to my images. So if I get the manually, this should be necessary? Or would it affect the reconstruction of the electrodes?
And thanks for a really nice software, I’m really curious about it.
Markus08/31/2016 at 4:41 PM #1422
Regarding export from electrodes to nifti: Would it help you to be able to export to a different surface format?
E.g. you can import .ply files in nearly any 3D visualization software including 3D Slicer and SurfIce. To export to .ply format, select the patients in Lead-DBS and then choose Export -> PLY from the Tools Menu of the main Lead GUI.
Exporting to nifti in general is not the best idea since electrodes are not the best option to be voxelized (they are small and you’d need high resolution to do so). However, you could convert the .PLY files to a voxelized version e.g. using Iso2Mesh by Qianqian Fang: http://iso2mesh.sourceforge.net/cgi-bin/index.cgi
Re the CT question: It’s not supported to rename files to l* or gl* anymore since Lead-DBS now reconstructs electrodes hybridly in native and MNI space. This may have worked in some early versions but doesn’t work anymore. Also, please note that any l* or gl* file needs to be in MNI space (!). That’s basically what l* and gl* prefixes stand for.
You have two options: 1. place a postop_ct.nii alongside your anat.nii or anat_t1.nii file into the folder and do co-registration between postop_ct and the primar anat file in Lead-DBS. This will generate the rpostop_ct.nii which will then be warped into MNI space in the normalization step.
2. place an rpostop_ct.nii alongside your anat.nii or anat_t1.nii into the patient folder. Lead-DBS will assume that the two files are exactly co-registered, i.e. have the same voxel resolution and nifti-header matrix.
After this, you need to run a valid normalization step. I’d recommend to use the ANTs SyN approach or if you have multiple anatomical files (e.g. anat.nii (=T2), anat_t1.nii (=T1), anat_pd.nii (=PD) and dti.nii (will generate fa2anat.nii file and white-matter anisotropy will be used for normalization, too) the ANTs Multimodal approach.
You can of course program your own normalization routine if you want things to be warped differently. It may not be completely trivial but if you’re good at programming, it’s doable. Any file called ea_normalize_*.m will be recognized by the Lead-DBS GUI.
Re the second question: I’d always prefer T2 for postop but T1 works as well. You can also call your postop t2 “postop_tra.nii” and your t1 “postop_cor.nii” and both will be normalized into MNI space. You can then swap image names to see which gives you the better precision in the manual reconstruction step.
Finally, as described above, the normalization step is an integral part of the Lead-DBS routine, so you definitely need to perform it. Nothing will work if you don’t. Still, this doesnt limit you to working inside MNI space. You can visualize results in either MNI or native space lateron. Since Lead-DBS has originally been designed as a research tool, MNI space based routines are much better maintained and tested.
So to answer your question, no, normalization is not only used to get structures to your image.
Hope this helps! Let me know if you have further questions!
You must be logged in to reply to this topic.