annot.outline as a background

[AndrewLawrence]

I am trying to combine annot.outline (as a background) with a glm result as an overlay (specifically a cluster-masked sig).

annot.outline looks great on its own, but when used as a background in vis.symmetric.data.on.subject the outlines appear monochrome black. I don't hate this, but it would be good to have the colour.

Apologies if I've misread/misunderstood the docs or missed a known bug that explains this.

Bonus Question: is there a way to make the overlays in vis[.symmetric].data.on.subject semi-transparent? E.g. an alpha argument akin to desaturate? I guess this is not that easy with rgl, but I didn't see it in the faqs.

Thanks in advance,

Andrew

---

The expected background:

The result I get with vis.symmetric.data.on.subject

Environment:
Windows 10
R 4.0.3
fslbrain 0.5.0 (from github)

Script

library(fsbrain)
library(freesurferformats)

# fsbrain::download_fsaverage(accept_freesurfer_license = TRUE)
avpath <- fsbrain::fsaverage.path()

lh_annot <- subject.annot(avpath, "fsaverage", "lh", "aparc")
rh_annot <- subject.annot(avpath, "fsaverage", "rh", "aparc")
lh_inf <- subject.surface(avpath, "fsaverage", "inflated", "lh")
rh_inf <- subject.surface(avpath, "fsaverage", "inflated", "rh")

aparc_outline <- list(
  lh = fsbrain::annot.outline(annotdata = lh_annot,
                              surface_mesh = lh_inf,
                              outline_color = NULL),
  rh = fsbrain::annot.outline(annotdata = rh_annot,
                              surface_mesh = rh_inf,
                              outline_color = NULL)
)

lh_demo_cluster_file = system.file("extdata", "lh.clusters_fsaverage.mgz", package = "fsbrain", mustWork = TRUE);
rh_demo_cluster_file = system.file("extdata", "rh.clusters_fsaverage.mgz", package = "fsbrain", mustWork = TRUE);
lh_clust = freesurferformats::read.fs.morph(lh_demo_cluster_file);   # contains a single positive cluster
rh_clust = freesurferformats::read.fs.morph(rh_demo_cluster_file);   # contains two negative clusters


# atlas borders have colour:
cm1 <- vis.color.on.subject(avpath, "fsaverage",
                     color_lh = aparc_outline$lh,
                     color_rh = aparc_outline$rh,
                     surface = "inflated",
                     views = "t4",
                     rglactions = list(no_vis = TRUE))

# atlas Borders are black:
cm2 <- vis.symmetric.data.on.subject(avpath, "fsaverage",
                              lh_demo_cluster_file,
                              rh_demo_cluster_file,
                              surface = "inflated",
                              views = "t4",
                              bg=aparc_outline,
                              rglactions = list(no_vis = TRUE))

# write out images:
vis.export.from.coloredmeshes(cm1, output_img = "cm1.png", img_only = T)
vis.export.from.coloredmeshes(cm2, output_img = "cm2.png", img_only = T)

[dfsp-spirit]

Hi Andrew,

thanks for the report and the great reproducible example. I can confirm that this seems to be a bug and I am looking into it.

On the question regarding semi-transparent overlays: I also thought of that and it would be great to have that. I can't remember right now what exactly was the issue with that, but last time I started working on it it turned out to be a major pain, but I think it can be done. I think that rgl does not accept an alpha channel in colors at all, all you can do is set the transparency of the material. But I could implement the layer merging in a way that would still allow layers with alpha values, only in the end there would need to be a fixed (non-alpha) background color onto which all layers must be merged, resulting in a final non-alpha color passed to rgl.

btw: I am working on something that should speed up the mesh neighborhood computation required to compute the outlines, it's too slow atm.

[AndrewLawrence]

I am looking into it

Amazing, thanks!

there would need to be a fixed (non-alpha) background color onto which all layers must be merged, resulting in a final non-alpha color passed to rgl

From my position of near total ignorance about the inner workings of rgl... that would certainly seem to fit OK for the vis functions that have a bg argument - if there's no bg specified you could ignore and warn user if transparency is requested.

I am working on something that should speed up the mesh neighborhood

Great, it is a bit slow! For this purpose (common space = fsaverage) I have pre-computed it once and saved to the project directory.

Thanks for providing this package to all - it's really useful!

[dfsp-spirit]

See also bug #14, I think this is related.