search

poldracklab / pydeface

defacing utility for MRI images
MIT License
112 stars 42 forks source link

t2w scan defacing #20

Open leej3 opened 6 years ago

leej3 commented 6 years ago

Hi I was wondering about the best way to get robust T2w defacing and thoughts on whether changing the code a bit would be desired.

Currently the best way seems to be to deface a T1w scan and then pass the result as a template for subsequent pydeface run for defacing a T2w scan. Alternatively one could register all scans to the T1w scans first and then use the --applyto option. My questions are: a) Would it be worthwhile integrating this into a more convenient interface i.e. pass pydeface a T1w scan and a list of other scans. Pydeface would first deface the T1w and then use the result as a template for the subsequent scans. Effectively a --applyto_with_reg flag. b) Would it be worthwhile to use something like epi_reg to make this more robust? c) Can I submit a pull request documenting outlining the best way to deface these types of scans. My naive attempts had me just defacing T2w with the default template and hacking off large portions of the brain.

chrisgorgo commented 6 years ago
leej3 commented 6 years ago

Cool. I like the idea of the bids app alright. I'll have a go at that.

chrisgorgo commented 6 years ago

Thanks!

Best, Chris

On Mon, Feb 26, 2018 at 10:40 AM, john lee notifications@github.com wrote:

Cool. I like the idea of the bids app alright. I'll have a go at that.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/poldracklab/pydeface/issues/20#issuecomment-368603910, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOkp0eRKrccfRXSXDtMpR4EYSOQMSIxks5tYvqXgaJpZM4STav2 .

leej3 commented 6 years ago

I have not got round to this yet. Still planning on it though. To extend this tool to other populations - pediatric, toddler, neurodegenerative disease patients - one may not have access to templates across multiple modalities in which case the apply_to_with_reg flag would be a useful plan B. Otherwise the code base would start filling up with templates...

dmd commented 3 years ago

3 years later - is there an established way to do this in pydeface, or have people moved on to other tools, or what?

leej3 commented 3 years ago

It’s a two step process, and was not tidied up beyond that.

@adamt has worked with this more recently, any tips?

AdamT commented 3 years ago

It’s a two step process, and was not tidied up beyond that.

@AdamT has worked with this more recently, any tips?

@leej3 I believe I've been mistagged as I'm not involved with this project. Cheers 👋

ofgulban commented 3 years ago

@dmd , I think one established way is: "one could register all scans to the T1w scans first and then use the --applyto option". Attaching an old pull request in case if it helps: #15

agt24 commented 3 years ago

Yeah, this worked well for us on a recent dataset. @Arshitha did the scripting. @Arshitha can you share the command line options you used?

Arshitha commented 3 years ago

@agt24 I've documented the pydeface workflow we used here The jupyter notebook has all the flags with a brief explanation of the modifications we made. Happy to answer any questions if this doesn't help.

agt24 commented 2 years ago

@Arshitha and @ericearl were chatting about this today. In that conversation, I realized there are some very non-obvious and non-documented details about our pipeline that took me some head scratching to recall the rationale for. So I thought I'd document them here. Here's the command line calls from the notebook @Arshitha referenced above:

PART 1: 
1. `fslmaths facemask.nii.gz -binv facemask_inv` (inverting default facemask)
2. `pydeface sub-ON01802_ses-01_acq-mprage_run-01_T1w.nii.gz --facemask ../../pydeface-defaults/data/facemask-inv.nii.gz --nocleanup --verbose --debug > T1w-deface-facemask-inv.txt`
3. `fslmaths sub-ON01802_ses-01_acq-mprage_run-01_T1w_pydeface_mask.nii.gz -binv inverted-T1w-pydeface-mask`
4. `fslmaths inverted-T1w-pydeface-mask.nii.gz -mul sub-ON01802_ses-01_acq-mprage_run-01_T1w.nii.gz sub-ON01802_ses-01_acq-mprage_run-01_T1w-new-mask-defaced.nii.gz`

PART 2: 
a. FLAIR 
- `pydeface sub-ON01802_ses-01_acq-2d_run-01_FLAIR.nii.gz --template sub-ON01802_ses-01_acq-mprage_run-01_T1w.nii.gz --facemask inverted-T1w-pydeface-mask.nii.gz --nocleanup --verbose --force --debug > flair_pydeface.txt`
- `fslmaths sub-ON01802_ses-01_acq-2d_run-01_FLAIR_pydeface_mask.nii.gz -binv inverted-flair-pydeface-mask`
- `fslmaths inverted-flair-pydeface-mask -mul sub-ON01802_ses-01_acq-2d_run-01_FLAIR.nii.gz sub-ON01802_ses-01_acq-2d_run-01_FLAIR_new-mask-defaced.nii.gz` 

b. T2w 
- same as above. Repeat for all modalities

We did the fslmaths inverting and uninverting before and after pydeface to deal with a problem we encountered on scans with largish fields of view (FOV). When the facemask was transformed into the space of the input ToBeDefaced volume, voxels outside of the FOV of the original facemask volume showed up as 1's instead of zeros. This sometimes caused some non-face portions of the input ToBeDefaced volume to be masked out which caused problems in later processing. (I'll post some screenshot if/when I can find them)

I'm curious if others have encountered this issue and if there are other approaches to address it.