# 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:** 20\ **Page:** 1
**Author:** ![rgrazioplene](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rgrazioplene/32/284_2.png) [@rgrazioplene](https://community.mrtrix.org/u/rgrazioplene)\ **Post date:** [October 3, 2016, 5:05pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/1 "2016-10-03T17:05:56Z")
Hi, I am new to mrtrix and I am having some trouble with generating appropriate masks for my images. All dwi data has been motion/eddy corrected in fsl. I then converted the data to .mif format: mrconvert -fslgrad bvecs bvals data.nii.gz data.mif and I am running dwi2mask on these images: dwi2mask data.mif data\_brainmask.mif However, several subjects have holes/gaps in their mask images: ![](https://community.mrtrix.org/uploads/default/original/1X/a8d75fb7fc14b961df0b0eb5ec80b6916f96cf44.png) ![](https://community.mrtrix.org/uploads/default/original/1X/7c09ff28497bf0d464e4d82ebce33e6213f977c7.png) I may be missing something obvious, but any advice would be appreciated. As you might imagine, this is creating problems down the line when I try to coregister across subjects. Best, Rachael ---
**Author:** ![rgrazioplene](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rgrazioplene/32/284_2.png) [@rgrazioplene](https://community.mrtrix.org/u/rgrazioplene)\ **Post date:** [October 3, 2016, 9:26pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/2 "2016-10-03T21:26:50Z")
To clarify–I realize it is possible to manually edit these masks in mrview, but would like to avoid that since I have many subjects. The problem is occurring in most of the subjects. ---
**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:** [October 3, 2016, 9:56pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/3 "2016-10-03T21:56:00Z")
Hi @rgrazioplene, `dwi2mask` uses a very simple strategy, and is indeed not perfect. The first thing to check here is probably whether you have corrected for bias fields (intensity inhomogeneities)? If not, maybe have a go at `dwibiascorrect` first, and see if `dwi2mask` performs better after correcting for bias fields. 🙂 Cheers, Thijs ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [October 3, 2016, 10:33pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/4 "2016-10-03T22:33:19Z")
Probably unrelated, but it might have an influence on this: it looks like your images have much higher in-plane resolution than through plane. Is this the case? If so, is this due to zero-filling interpolation on the scanner (the default on GE and to some extent Philips scanners)? I’ve typically found that images interpolated in this way don’t produce such good results - sometimes a lot worse. And this is particularly the case for noisy images, since interpolating noise produces strange-looking images and introduces funny artefacts in the reconstructed images (in fact, someone once told me their on-scanner DTI-based fibre tracking performed better once they figured out how to disable zero-filling). This may interact with `dwi2mask` at least to some extent. I reckon it would be worth figuring out if this is the case, and trying to disable it if you can - although I realise it is a bit late for your study now that the data have been acquired… ---
**Author:** ![Romain\_Valabregue](https://community.mrtrix.org/user_avatar/community.mrtrix.org/romain_valabregue/32/2691_2.png) [@Romain\_Valabregue](https://community.mrtrix.org/u/Romain_Valabregue)\ **Post date:** [October 4, 2016, 9:30am UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/5 "2016-10-04T09:30:32Z")
Hi I also encounter this problem : I get holes in low SNR region (particulary in the deep brain structures), which make sens if one take a threshold approach. to solve the problem I just took the mask from fsl (generated with bet2) Cheers, Romain ---
**Author:** ![rgrazioplene](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rgrazioplene/32/284_2.png) [@rgrazioplene](https://community.mrtrix.org/u/rgrazioplene)\ **Post date:** [October 4, 2016, 2:02pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/6 "2016-10-04T14:02:33Z")
Thanks for the suggestion! I considered this–however, unless I’m misreading something, dwibiascorrect needs a brainmask to run, so there’s a bit circularity problem. ---
**Author:** ![rgrazioplene](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rgrazioplene/32/284_2.png) [@rgrazioplene](https://community.mrtrix.org/u/rgrazioplene)\ **Post date:** [October 4, 2016, 2:03pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/7 "2016-10-04T14:03:41Z")
Awesome–That is what I decided to try as of last night! I’m VERY glad to hear that you’ve had success with fsl masks. I was not looking forward to a return of the not-so-nostalgic days of manual volume editing. ---
**Author:** ![rgrazioplene](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rgrazioplene/32/284_2.png) [@rgrazioplene](https://community.mrtrix.org/u/rgrazioplene)\ **Post date:** [October 4, 2016, 2:17pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/8 "2016-10-04T14:17:47Z")
Yes, data collection is over–it was collected on a Siemens scanner, but by no means does that rule out zero-filling interpolation. ---
**Author:** ![rgrazioplene](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rgrazioplene/32/284_2.png) [@rgrazioplene](https://community.mrtrix.org/u/rgrazioplene)\ **Post date:** [October 4, 2016, 6:31pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/9 "2016-10-04T18:31:57Z")
Hi Romain, did you also need to generate masks for upsampled/scaled images (e.g. for the fixel based analysis pipeline)? The instructions [here](http://mrtrix.readthedocs.io/en/latest/workflows/fixel_based_analysis.html) say to compute a mask on the upsampled normalised dwi images (scaled to 2.0). Although these images have been bias corrected and normalised, I’m still getting holes when I run: dwi2mask input\_upsampled\_dwi output\_upsampled\_mask Do you (or anyone else) know if it would be appropriate to do the following instead? mrresize input\_dwi\_original\_sized\_mask -scale 2.0 output\_upsampled\_dwi\_mask ---
**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:** [October 4, 2016, 11:39pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/10 "2016-10-04T23:39:31Z")
> [@rgrazioplene](#): > > dwibiascorrect needs a brainmask to run, so there’s a bit circularity problem 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. ---
**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:** [October 4, 2016, 11:48pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/11 "2016-10-04T23:48:50Z")
> [@rgrazioplene](#): > > Do you (or anyone else) know if it would be appropriate to do the following instead? > > mrresize input\_dwi\_original\_sized\_mask -scale 2.0 output\_upsampled\_dwi\_mask We’ve actually found ourselves that this approach, rather than `dwi2mask`’ing the upsampled data (which is indeed what the tutorial suggests doing), gives better results in some cases. Maybe @Dave can comment on this one as well. 🙂 However, take into account that the mask is supposed to be a binary (bitwise) image; so the default options as to interpolation and datatype in `mrresize` are not optimal for these type of images. By default, `mrresize` uses cubic interpolation and stores the result as a floating point image. Instead, the way to go for this scenario would be: ```auto mrresize input_dwi_original_sized_mask -scale 2.0 output_upsampled_dwi_mask -interp nearest -datatype bit ``` …i.e., nearest-neighbour interpolation and storing the result as a bitwise image. ---
**Author:** ![rgrazioplene](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rgrazioplene/32/284_2.png) [@rgrazioplene](https://community.mrtrix.org/u/rgrazioplene)\ **Post date:** [October 6, 2016, 2:01pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/12 "2016-10-06T14:01:06Z")
Thanks so much for your helpful and informative replies. I tried this method, and it seems to be working. ---
**Author:** ![SimonDavis](https://community.mrtrix.org/user_avatar/community.mrtrix.org/simondavis/32/3489_2.png) [@SimonDavis](https://community.mrtrix.org/u/SimonDavis)\ **Post date:** [January 5, 2017, 3:12pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/13 "2017-01-05T15:12:34Z")
I’ve been having the same issue, working with a lot of older adult data and the wholes pop up everywhere. Played around a little with the clean\_scale parameter, and though it grew/shrank the mask, the holes were still there (and it started including eyeballs). Tried bias correction, no big difference. At this point I’ll have to rely on bet (how i hate playing the fractional intensity game!). I get the impression that dwi2mask is doing something more than the geometric bet solution, especially for dwi data with multiple bvals. Could any of you comment on how the computation compares between bet vs dwi2mask? ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [January 6, 2017, 3:01am UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/14 "2017-01-06T03:01:07Z")
I’ll leave discussion of the mask cleaning filter to @Thijs, but I’ll have a go at this: > I get the impression that dwi2mask is doing something more than the geometric bet solution, especially for dwi data with multiple bvals. Could any of you comment on how the computation compares between bet vs dwi2mask? `bet` and `dwi2mask` are completely different algorithms, apart from the intended outcome. - `bet` attempts to draw a closed mesh surface around the brain using vertices and triangles. AFAIK, it’s intended to operate primarily on T1 images, but people still use it on DWI data, presumably using the mean _b_=0 image? So it tries to place the vertices of the surface at the outer edge of the brain (where the intensity gradient is greatest), and then fills the voxels within that surface only when generating the output mask image. - `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. There are then image-based filtering operations that try to make the mask as ‘brain-like’ as possible (e.g. removing any voxels not connected to the ‘biggest blob’ (the brain), filling any holes, combining results across shells), but fundamentally it’s an image intensity-based segmentation - hence why a B1 bias field can have such a large influence. Both are far from bullet-proof solutions unfortunately. I’m sure a lot of us have had ideas for better ways to solve this problem, but it’s perhaps not the most ‘fun’ thing to work on… ---
**Author:** ![SimonDavis](https://community.mrtrix.org/user_avatar/community.mrtrix.org/simondavis/32/3489_2.png) [@SimonDavis](https://community.mrtrix.org/u/SimonDavis)\ **Post date:** [January 10, 2017, 6:14am UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/15 "2017-01-10T06:14:02Z")
Wow, super helpful information! TBH I’ve used bet for different reasons in different contexts–its nice to do a very lenient skull stripping just to remove all the non-zero voxels outside the skull, to cut down on file size and computation time. Lately I’ve been wanting to coregister my DWI, T1, T2, and MTI data together, so the bet mask helps. 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. Dwi2mask still leaves a bit of noise outside the skull, so I might insert another bet at the end if i can figure out the right values. Thanks so much! S ---
**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? ---
**Author:** ![Alistair\_Perry](https://community.mrtrix.org/user_avatar/community.mrtrix.org/alistair_perry/32/416_2.png) [@Alistair\_Perry](https://community.mrtrix.org/u/Alistair_Perry)\ **Post date:** [December 13, 2017, 11:34pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/17 "2017-12-13T23:34:36Z")
> [@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. I’m having success with a similar procedure. I perform `bet2` on the meanb0 image post-eddy correction, then use the subsequent mask for `dwibiascorrect`. After this, I use `dwi2mask` on the biascorrected image. For high b-value date, It’s worthy to note that this procedure only works when using `-fsl` argument into `dwibiascorrect`. With `ants` correction: ![image](https://community.mrtrix.org/uploads/default/original/2X/9/9c5f9f40d5704f7d247a80d6067e8cb7ee1144d2.jpg) Now FSL: ![image](https://community.mrtrix.org/uploads/default/original/2X/7/7621b37e764295e0f6993e6210771b4a4abb4f8a.jpg) ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [December 19, 2017, 3:20am UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/18 "2017-12-19T03:20:04Z")
> For high b-value date, It’s worthy to note that this procedure only works when using `-fsl` argument into `dwibiascorrect`. Do you have a sense as to why this is the case? While the two algorithms definitely give different bias field estimates, I wouldn’t have expected them to vary enough for the subsequent performance of `dwi2mask` to vary so massively. ---
**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 17, 2018, 4:44am UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/19 "2018-01-17T04:44:01Z")
> [@rsmith](#): > > While the two algorithms definitely give different bias field estimates, I wouldn’t have expected them to vary enough for the subsequent performance of dwi2mask to vary so massively. This can come down to a small difference as well. @Alistair_Perry’s example above would be such a case: `dwi2mask` at some point fills holes in the mask; the outcome of that step can vary massively based on whether such a hole would be “closed off” / encapsulated in the mask (in which case it’s successfully filled), or whether there’s even a single-voxel wide path still connecting the hole to the outside (where it wouldn’t fill up, such as in case of the yellow mask shown by @Alistair_Perry). There’s not much that can be done about that, within the constraints of the data driven approach of `dwi2mask`, but having a more properly biasfield-corrected input dataset definitely helps a lot to avoid this problem happening. Iterating `dwi2mask` with bias field correction would eventually do the job as well. It’s ultimately a chicken-and-egg problem, where a good mask benefits bias field correction, and good bias field correction benefits (intensity driven) mask estimation. ---
**Author:** ![trang229](https://community.mrtrix.org/user_avatar/community.mrtrix.org/trang229/32/1293_2.png) [@trang229](https://community.mrtrix.org/u/trang229)\ **Post date:** [May 2, 2018, 2:06pm UTC](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484/20 "2018-05-02T14:06:30Z")
Can you give me a hint for fix it manually?? I got same problem [Next page](https://community.mrtrix.org/t/dwi2mask-holes-in-mask-images/484.md?page=2)