DEC TDI overlay on structural image?

Continuing the discussion from Understanding output of iFOD2 vs. SD_stream: Now that @rsmith helped me understand global/local tractography techniques and TDI at the ISMRM educational session last week, I’d like to overlay the color TDI on the registered T1 image. Is there a nifty command to perform this in MRtrix?

Assuming MRView’s Overlay tool isn’t sufficient for your purposes, then I guess you could use mrcalc to merge the two images, having resampled one onto the other first. Something like this will probably work for you:

$ mrtransform TDIC.mif -template anat.mif TDIC-resliced.mif
mrtransform: [100%] reslicing "TDIC.mif"
$ mrcalc anat.mif TDIC-resliced.mif 100 -mult -add merged.mif
mrcalc: [100%] computing: (anat.mif + (TDIC-resliced.mif * 100))

in this case, I’m just adding the anatomical with the colour TDI (having resliced it to the anatomical), scaling the TDI by a factor of 100. Note this uses mrcalc's handy broadcasting feature (inspired from NumPy) to combine the single-volume anatomical image with the 3-volume colour TDI. :nerd:

1 Like

Hey @jdtournier, perfect answer. For some reason mrview’s Overlay tool left black voxels, where the mrcalc does a merge just like I was looking for.

Part of the reason I want to avoid mrview (no offense!) is to make a completely automated, background process and keep people out of the loop.

Here are my results with mrcalc:

But with mrview (anatomy base, TDI overlaid):

Good to hear. The ‘holes’ you’re seeing correspond to zero or low streamline densities. You can adjust the display using the Overlay tool’s (lower) threshold control.
Cheers,
Donald.

For some reason mrview’s Overlay tool left black voxels, where the mrcalc does a merge just like I was looking for.

This occurs because the capabilities when updating an existing framebuffer with new image data in OpenGL are surprisingly crude. Setting the overlay image threshold value can help, but only ever acts as a binary mask. A trick I sometimes use in such circumstances is to hide the overlay, take a screenshot, make the overlay image completely opaque, take another screenshot, then use image editing software e.g. GIMP to combine them (where you can experiment with different layer combination settings).

But for something automated, mrtransform | mrcalc is indeed the way to go.

Well, that’s not strictly speaking the issue here. If we wanted to blend the two images using the same addition operation as the mrcalc command does, we could (using the overlay’s intensity as the alpha value). But the overlay tool is designed to work differently, using a fixed alpha value (as given by the transparency slider) on a thresholded overlay. The idea was that this mode of operation was probably the most likely to be needed in practice (e.g. overlaying significance blobs, etc.).

If there is demand, it should be possible to offer a drop-down menu (combobox) for different blending modes. Currently, it’s fixed alpha, but we could also offer addition, subtraction, overlay, underlay, etc (a bit like the GIMP’s layer modes - though maybe not quite that many…). There’s a fair bit of flexibility there if we want it. Feel free to open a feature request if this is something you’d like to see implemented in MRView.

@jdtournier / @rsmith Is there a good way to export the 3-volume TDI/DEC map to PNG within mrtrix? Or (better), can the 3-volumes be mrconvert-ed to 3 individual files? Somehow I think -strides can do this?

No easily scriptable export to PNG, but you can definitely split the file into three individual volumes using MRtrix3’s own numbered file syntax, e.g.:

$ mrconvert tdi.mif split-tdi-[].mif
1 Like

Exporting to PNG at native resolution would definitely be helpful; in fact it’s the oldest outstanding GitHub issue. I do have personal code to do it (well, exports to PGM / PPM which can then be converted externally), which I use often but is kinda clunky. Let me know if that would still be of benefit to you over and above volume splitting.

@rsmith, Thanks for the offer, but I’m good to go. Now that I have the RGB components split into volumes, I can make the DICOM secondary captures that I’m after directly. I needed PNGS, if I couldn’t get at the RGB easily (my DICOM conversion code doesn’t read 4D nifti just yet).