Error Calculating Overlapping Volumes and Writing to Text File

[wtmccuddy]

Hello,

Thank you creating this software and for making it relatively easy to implement for a novice (took me a few tries to realized my GPU memory of 2GB was not sufficient to run fastsurfer with cuda and that I needed to downgrade from freesurfer v7 to v6).

After running on a test subject I received the follow error in error log: "mghRead(/home/prism/Desktop/Sub001//output_VBG/sub-JW001/sub-JW001fastsurfer/sub-JW001/mri/aparc+aseg.mgz, -1): could not open file"

Sure enough, there was no aparc+aseg.mgz in the mri directory. I assume this error also caused the script to fail to write overlapping volumes to the text file, "percent_lobes_lesion_overlap_report.txt" which was empty (except for the prefilled templated text with blanks for number of voxels).

Any idea what is cause this error and how to fix it?

PS: KUL_VBG_prep_log_2022-02-23_10-57-08.txt

Thanks,

Travis

[KUL-Radneuron]

Hi Travis,

Thanks for your interest in KUL_VBG.

I just checked out the log file you sent (thanks).

It seems that FastSurfer didn't finish correctly however, I can't find any evidence of that in the log file.

Do you have an aparc+aseg.orig.mgz and an aparc.mapped+aseg.mgz in Fastsurfer_output/mri ?

If you find these files then actually FastSurfer finished correctly, but the FreeSurfer tools we're using to calculate lesion overlap with different labels is not compatible with FastSurfer and will need an update.

Did you use -P 2 for this run? If so would you be willing to try -P 1 and/or -P 3 ? Since you're not using GPU accelerated FastSurfer then it shouldn't make a big difference time-wise to run -P 3 (hybrid approach) or -P 1 (FreeSurfer only).

The lesion overlap reporting part relies on FreeSurfer tools such as mri_annotation2label and mri_aparc2aseg that seems to require FreeSurfer folder structure and naming convention to work correctly.

Best, Ahmed Radwan

[wtmccuddy]

Hello Ahmed,

Thanks for the quick response. I have the aparc+aseg.org.mgz file BUT NOT the aparc.mapped+aseg.mgz file.

Yes, I used -P 2. I'm rerunning it now using -P 3. I'll let you know if that gives me both the files you mentioned.

Does freesurfer need to be in the same dir as other KUL_apps? Right now, I have freesurfer in /usr/local and VBG and fastsurfer in /usr/local/KUL_apps. I'm under the impression that freesurfer can be installed anywhere as long as it's sourced correctly.

Travis

[Rad-dude]

Hi Travis,

I think the missing aparc.mapped+aseg.mgz file may relate to the lack of --fsaparc in the fastsurfer call for -P 2. That's easy to change, you could simple add --fsaparc to line 2846 (I will add it to the next update).

Both FreeSurfer and FastSurfer can be installed anywhere as long as they sourced correctly, same goes for all dependencies.

Yes, please let me know what happens with -P 3.

Best, AR

[wtmccuddy]

Hello,

Sorry for the delay in getting back to you. The -P 3 flag ran (took ~76 hours on CPU; I really need to upgrade my GPU) and was successful. Again, the script produced the parc+aseg.orig.mgz file but not the aparc.mapped+aseg.mgz.

I just saw your note about adding --fsaparc to line 2846. This is referring to the KUL_VBG.sh script, correct?

That is, changing:

--sid ${subj} --sd ${fasu_output}/${subj} --parallel --threads ${ncpu} \ to --sid ${subj} --sd ${fasu_output}/${subj} --parallel --threads ${ncpu} --fsaparc \

Correct?

Travis

[KUL-Radneuron]

Hi Travis,

I'm surprised it took so long with -P 3, but then again I usually run FastSurfer on GPU. The log should tell you how long each step took, I'm curious to know if it was FastSurfer or FreeSurfer that ran for so long.

Does this mean the lesion overlap part of the workflow ran successfully?

Could you do a quick scan of the log file for errors?

Indeed, I was referring to KUL_VBG.sh line 2846, where you could add this --fsaparc -> "--sid ${subj} --sd ${fasu_output}/${subj} --parallel --threads ${ncpu} --fsaparc"

However, the -P 3 should have this option in, that's on line 2993, so I expected that you would end up with aparc.mapped+aseg.mgz.

Did you try with -P 1 also (that's a pure FreeSurfer run)?

The runtime for parcellation should be dependent on the quality of the lesion-filling, if the lesion filling didn't go so well, then I expect a long runtime for parcellation, but if it did then it should go rather quickly (about 6 hours or so for FreeSurfer).

Could you please check the filled image?

If you're able to share the T1 nifti (perhaps after defacing) and lesion mask, I could try it out with GPU acceleration.

Best, AR

[wtmccuddy]

It looks like Freesurfer's topology correction took ~25 hours for left hemi and ~37 hrs for right hemi and it was only running on 1 cpu thread for some reason. I though part of the issue might have been that I didn't do a great job segmenting the lesion. However, the lesion is in the left hemisphere, but there were more errors in topology in the right hemisphere.

The lesion overlap part of the workflow still did not run successfully. Originally (with -P 1) the percent_lobes_lesion_overlap_report.txt file did not contain any values for ROI voxel count, cmm volume, or overlaps. After the second run (with -P 3) the ...overlap_report.txt file contained voxel counts and volumes for ROIs, but still no overlap values.

I will try again with -P 1 over the weekend. Do you know how I can increase number of threads used by freesurfer during topology correction?

Attached below are the log file and VBG filled brain. The original T1 (now defaced) will not attach for some reason. I will try sending on its own in another message.

KUL_VBG_prep_log_2022-02-24_09-49-49.txt

sub-JW001_T1_nat_filled_brain.nii.gz

Thanks again for you help!

T

[wtmccuddy]

link to defaced T1wC MRI from which mask for VBG was created.

https://drive.google.com/file/d/1Cqo6Ynko6IwfLRNvjKadtiTZuOEhrJsj/view?usp=drivesdk

P.S. if I remember correctly, in the paper you published on VBG you mention potentially integrating the open source automatic lesion segmentation protocol currently implemented in the CBICA software, CaPTk. Is this still something that is planned?

T

[KUL-Radneuron]

I believe FreeSurfer's topology correction is by default a single-threaded operation running on each hemisphere separately, would be nice if that could be parallelized but I am unaware of how to do so. Maybe ask on the FreeSurfer email forum if it's possible?

Thanks for sharing the data, a quick look shows that thalamic and basal ganglia intensities are a bit lower than expected, not too far off though. The filling seems okay besides the Thalamic/BG hypointensity. The input is a contrast-enhanced T1 though, which is sometimes problematic with FS, see supplementary info of the VBG NIMG paper (figure below), and also here https://doi.org/10.1007/s00330-021-08405-8. [image: image.png]

Do you also have precontrast T1 images?

Regarding automatic lesion segmentation: Have a look at https://github.com/treanus/KUL_NIS/tree/dev script: KUL_anat_segment_tumor.sh

The appropriate approach largely depends on the pathology in question.

Best, AR

On Sat, 5 Mar 2022 at 18:59, wtmccuddy @.***> wrote:

link to defaced T1wC MRI from which mask for VBG was created.

https://drive.google.com/file/d/1Cqo6Ynko6IwfLRNvjKadtiTZuOEhrJsj/view?usp=drivesdk

P.S. if I remember correctly, in the paper you published on VBG you mention potentially integrating the open source automatic lesion segmentation protocol currently implemented in the CBICA software, CaPTk. Is this still something that is planned?

T

— Reply to this email directly, view it on GitHub https://github.com/KUL-Radneuron/KUL_VBG/issues/10#issuecomment-1059806195, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQV4J3HR53533YUB3Q24Y43U6OOJLANCNFSM5PGFGPKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[saruarlive]

@KUL-Radneuron @Rad-dude Very interesting work. I have a query regarding the lesion filled sub-JW001_T1_nat_filled_brain.nii.gz image. We can see large black regions in the image as attached here (a similar black region was detected when I ran 100+ subjects). Is it some sort of bug in the pipeline? Could you talk a bit more in regard!!!

One more query is, should the lesion be connected for smooth lesion filling? Lets say a lesion has several connected components (4+) at both laterals (LT & RT). Will the lesion filling be smooth under the circumstances?