# Dwi2mask: holes in mask images **URL:** \ **Category:** Uncategorized\ **Created:** [October 3, 2016, 5:05pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484 "2016-10-03T17:05:56Z")\ **Posts on this page:** 1\ **Showing post:** 16
**Author:** ![ThijsDhollander](https://community.mrtrix.org/user_avatar/community.mrtrix.org/thijsdhollander/32/1617_2.png) [@ThijsDhollander](https://community.mrtrix.org/u/ThijsDhollander)\ **Post date:** [January 10, 2017, 8:08am UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/16 "2017-01-10T08:08:32Z")
> [@rsmith](#): > > `dwi2mask` is a purely image-based approach. It assumes that for each b-value shell (mean value across directions for b != 0), it’s possible to select an intensity threshold that separates brain from non-brain. Minor correction: also for the b=0 “shell”. Otherwise, you’d get a big hole in the mask quite often (the ventricles, as they are often connected to the space outside the brain). > [@SimonDavis](#): > > But more to the problem in this thread, I’ve found over the past couple of days that a back-and-forth procedure is working best, with first a very lenient bet on all 3 b0’s (f = 0.2), average the b0’s, bias correction, then dwi2mask. Yes, that makes sense. More generally, to quote myself from somewhere earlier in this thread: > [@Thijs](#): > > Yep, exactly. The two problems are definitely “connected” in that sense. However, the bias correction is a little bit less dependent on a “perfect” mask in order to generate a reasonable solution, whereas the threshold-based (at its core, plus some other additions) masking method is much more dependent on a reasonably good bias correction in order to do its job reasonably well. A lot of "reasonably"s in there. 😉 > > In practice, a (“reasonable”) approach given what’s currently available in MRtrix is to run dwi2mask first to get an initial mask (i.e. like the one you showed; imperfect but ok’ish at this stage), use that one to call dwibiascorrect, and use the bias corrected result again as an imput to dwi2mask. You could essentially just keep on iterating both to do a close-to-joint optimisation of both, but we find that in practice just doing “initial masking –\> bias field correction –\> final masking” will get you mostly there in a wide range of scenarios and data qualities. The bias field correction should mostly do away with the (too) low intensities that cause the holes, even when this bias field correction itself is provided with a sub-optimal mask that has holes, as the bias field is expected to be relatively smooth. The strength of `dwi2mask` is that, by using all of the average b=… contrasts, it finds the “exact” boundary of the brain (including CSF) pretty well in most places (after bias field correction, that is). Its weakness is that it may also find other non-brain bits (e.g., eyeballs), and even after the final step only selects the biggest connected component, some of those other non-brain bits can still be connected to the actual biggest component we’d like to end up with (e.g., an eyeball via the optical nerve, if the latter appears clearly enough). The mask cleaning filter (that can be controlled via the `clean_scale` parameter; but 2 is a very good default for typical resolutions) is designed to attack those attached bits in a conservative manner: it’ll cut them loose from the brain if they’re connected via a thin bridge, but only if the bit is bigger/wider than that bridge; think again of an eyeball attached via the optical nerve. Due to how it works, the mask cleaning filter typically doesn’t create any big holes in the middle of the brain; so there shouldn’t be any need to tune it down or switch it off. As you noticed, that’ll only result in the inclusion of those (eyeball and other) bits. In a way, it’s a shape prior that assumes the brain is a single big connected _and “compact”_ blob. It’s also not cutting off thin extensions that don’t end in another bigger blob, and when cutting of another bigger blob, it won’t cut the bridge too close to the actual brain, as this may just be a slightly sharper feature of the _actual_ brain. But at least it should get rid of the biggest mess (if such mess is present). `bet` only works on 1 image, so doesn’t benefit of all b-values. That challenge is “tackled” by a user controlled parameter. When set right, it can work decently on some data, but as you probably noticed, the challenge is in setting that _f_ parameter. For us, `dwi2mask` is mostly convenient, because it works directly on the dMRI dataset, and exploits most of the useful information in there (with regards to getting a mask), with minimal assumptions and no crucial parameter. The mask cleaning filter is a simple addition that focusses specifically on those extra bits we also typically observe in some datasets. In most typical processing pipelines in MRtrix, the mask serves just to limit the computations of the more expensive algorithms (e.g. CSD, fixel segmentation, etc…) to just the set of voxels that will reasonably be needed. Also, for some algorithms (e.g. registration), we do need to get rid of the bulk of any extra mess, so those voxels/areas don’t bias or distort the outcomes of such algorithms. But note that `dwi2mask` (and to be honest, `bet` as well) should never be used for an accurate, **and definitely not precise** , segmentation of the brain parenchyma (+CSF); i.e., don’t use it for brain volume measurements or something; at least not without inspecting the masks and cleaning them up manually if needed. So I reckon this is an important question you should ask yourself as well: what will you be using the mask(s) for? And consequently, how much time and effort is it worth spending to make them absolutely “perfect”? And what aspects of the mask are most important for your application? --- _[View the full topic](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484)._