Preliminary results with 3D Gaussian filtering (ignoring masked voxels) with a 9x9x9 kernel:

FYI: we have 4 different types of B1 filtering implemented in qMRLab, it's in MATLAB but here's a blog post about it: https://qmrlab.org/2019/08/08/b1filter.html

In particular, there's an interactive figure at the end that compares the B1 maps for 1 type of artifact. I didn't explore more in the blog post, but I've thought a lot about this over the years so have some more opinions on this.

FYI: we have 4 different types of B1 filtering implemented in qMRLab, it's in MATLAB but here's a blog post about it: https://qmrlab.org/2019/08/08/b1filter.html

Amazing!! Thank you so much for chipping in @mathieuboudreau ! Would you mind giving it a try and see if it improves things compared to our Gaussian filtering? I've made data available in the PR body.

EDIT 2022-07-29 10:51:51: From https://qmrlab.org/2019/08/08/b1filter.html Figure 6, I'd say that median (vs. gaussian) filtering might be more appropriate for our maps (which show some outliers).

EDIT 2022-07-29 10:51:51: From https://qmrlab.org/2019/08/08/b1filter.html Figure 6, I'd say that median (vs. gaussian) filtering might be more appropriate for our maps (which show some outliers).

Yeah, something that's always annoyed me is the lack of discussion in the B1 mapping community about when and why they use certain filters**. It's really going to be artefact/image dependent; for example, in AFI a common issue is a "stripping pattern" from Gibbs Ringing, and and median isn't going to work well unless you use a very large kernel. At the end of the day, you know that the true B1 map is smoothly varying and the purpose of the filter should just be to get close to that, but I found certain filters can do more harm than good in certain images. Unless I get a very odd artefact (eg, due to phase poles in a Bloch-Siegert map for example), my first choice would be median.

Another good way to check is by doing an absolute or % difference map between filtered and unfiltered, to see how the filter impacted your final map (eg just denoising, or did it attenuate values in regions, etc).

I'll test out this feature as you implemented this afternoon, and test out a median filtering implementation!

Opened a PR into this branch #3

It implements an initial draft of the median filter. It has better edge preservation than the scipy median_filter; it ignores NaNs from the median calculation, so it has better edge preservation. I also made a Jupyter Notebook to help generate some comparisons.

Here are the three orientation views of the original, median (5x5x5 voxel), and gaussian-filtered B1 maps:

To have a better view of what the filters are "removing", difference maps (%) relative to the original map are plotted next for one orientation:

Red -> filtered maps have higher value than original map, blue -> filtered maps have lower values

Lastly, a comparison between the two filtered-maps are plotted:

Zoom in to view specific differences (arrow):

(Note that this would probably smoothed out with a larger Gaussian kernel, or preserved with a 3x3x3 Median one.)

Also note that because the voxels are anisotropic (2x2x4), but the median filter is 5x5x5 voxel, more "filtering" is happening along the slice direction (which might lead to some systemic underestimations in B1 values), but this could be fixed by using the "footprint" option of the generic_filter tool.

Does this improve vs Gaussian filter? Using these parameters, I think so, but I haven't played around with the Gaussian
kernel size any more (I could play around with it a bit more next week). Also, I imagine that only the B1 values exactly in the spinal cord are of interest, so segmenting this ROI and comparing the values would help with the comparison. It'll still likely be subjective, there's no real ground truth here, it's a pull-push balance of 1) knowing the true B1 imap s expected to be a smooth function, but 2) if you try and make it too smooth by increasing the filter/kernel size, it will create systemic bias by typically lowering the B1 values due to including voxels too far away from the calculating pixel during the filtering.

@mathieuboudreau this is amazing! thank you so much for spending time doing this. I like results from the median filter better. I agree the kernel should be adjusted to the effective spatial resolution.

Great! I just pushed the changes to handle anisotropic pixel dimentions (eg slice thickness different from in-plane resolution) in commit f4db728 of my PR to this branch #3

Here's a gif of the difference (5x5x5 voxel kernel size vs 5x5x3 (rounded up the slice size)).