Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements when using N4BiasFieldCorrection #388

Closed
oesteban opened this issue Aug 28, 2019 · 9 comments

Comments

@oesteban
Copy link
Contributor

commented Aug 28, 2019

As a result of a thorough bug report from @Shotgunosine, in ANTsX/ANTs#822 several recommendations we should adopt for fMRIPrep are given:

@oesteban oesteban added this to the 1.0.0 milestone Aug 28, 2019

@oesteban oesteban added this to Triage in pipelines via automation Aug 28, 2019

@franklin-feingold franklin-feingold moved this from Triage to Issues A-list in pipelines Aug 29, 2019

@franklin-feingold franklin-feingold moved this from Issues A-list to Development backlog in pipelines Aug 29, 2019

@effigies

This comment has been minimized.

Copy link
Collaborator

commented Aug 29, 2019

From my understanding, we don't need to rescale, we just need to threshold the outputs of registration to >= 0.

@Shotgunosine

This comment has been minimized.

Copy link

commented Aug 29, 2019

@oesteban

This comment has been minimized.

Copy link
Contributor Author

commented Aug 29, 2019

Thresholding changes the distribution and the step it creates is exaggerated by the initial log transform of N4. It makes sense that rescaling works better.

@effigies

This comment has been minimized.

Copy link
Collaborator

commented Aug 29, 2019

If the issue is interpolation-induced negative values, then it's not clear that preserving that particular aspect of the distribution is worthwhile, as it's already an artifact. Rescaling while preserving these artifacts could shift the background noise up significantly.

@oesteban

This comment has been minimized.

Copy link
Contributor Author

commented Aug 29, 2019

It is undesired and it doesn't make sense as MRI signal, but not an artifact. BSpline interpolation can do this to ensure continuity of the distribution, which is necessary for N4 to find the bias field, which will become an additive offset after log transform.

Finding truncated values breaks the continuity constraints of the BSplines modeling the bias field.

@Shotgunosine

This comment has been minimized.

Copy link

commented Aug 29, 2019

As I'm trying to track my other masking bug down with this data, I've found that the output of split_opt_comb appears to already be partially brain masked. Is that correct behavior? If it is supposed to be masked, is that discontinuity going to disrupt the N4 normalization that happens when masking the bold after transformation to standard space?

@effigies

This comment has been minimized.

Copy link
Collaborator

commented Aug 29, 2019

Okay. So what if we transform the uniformized image, rather than uniformize the transformed image?

@effigies

This comment has been minimized.

Copy link
Collaborator

commented Aug 29, 2019

But @Shotgunosine, I think the issue here was specifically with blip-up/blip-down, which are registered to each other and then N4-corrected? Or was it the EPI masking in template space?

@Shotgunosine

This comment has been minimized.

Copy link

commented Aug 29, 2019

Yeah, that was where the N4 issue was occurring for this particular failure. I'm trying to track down other masking/registrations issues with other scans from this same dataset and I'm suspicious that those other issues may also be related to this same N4 issue. I can move questions about debugging that out to another thread till I've confirmed those suspicions though.

@oesteban oesteban modified the milestones: 1.0.0, 0.10.3 Aug 29, 2019

oesteban added a commit to oesteban/niworkflows that referenced this issue Aug 30, 2019
fix poldracklab#388: add a drop-in replacement for ``N4BiasFieldCorre…
…ction`` and set ``rescale_intensities`` if version is >=2.1.0

@oesteban oesteban moved this from Development backlog to In progress in pipelines Aug 31, 2019

@oesteban oesteban moved this from In progress to Awaiting review in pipelines Aug 31, 2019

@oesteban oesteban closed this in 406b4e5 Sep 9, 2019

pipelines automation moved this from Awaiting review to Done Sep 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.