Surface module produces images with empty, white sections

[grotegerd]

Description

If I run the surface module, it runs through without errors; however, most brain images are simply plain white sections, in some 1-2 regions are parcellated, but otherwise nothing. see screenshot. I have already tried different versions.

I have tested so far version 2.1.3 and 2.0.0 (installed with pip and also using apptainer image)

Freesurfer version used 7.4.1 (I also tried 8.0.0, did not work as well)

Expected Behavior

should produce screenshots showing all parcellations

Screenshots

Environment

• Python 3.11.2
• apptainer version 1.2.4-1.el8
• Debian 12

Execution

run_fsqc --subjects_dir testdir/ --output_dir qc_test/ --surfaces --surfaces-html

[kdiers]

Hello, and thanks for your report. We are planning to release version 2.1.4 with a different surface rendering engine during this or early next week, which will hopefully fix the issue.

[kdiers]

We have now released version 2.1.4, including an image on dockerhub.

Kindly let us know if the issue still persists, as we have not observed it in our tests so far.

Please note that there will be changes in running the docker and singularity version of the toolbox; the documentation has been updated already. Specifically, there will be one additional argument (--init) for the docker command, and a wrapper (xvfb-run) for the singularity command. Please see here and here for details.

[grotegerd]

Thanks a lot - that solved in general the error, surfaces are now plotted correctly when using the new version installed via pip.

Regarding usage via singularity on a headless server, I seem to run into a new issue:

[...]
[INFO: acceleratesupport.py:   17]: No OpenGL_accelerate module loaded: No module named 'OpenGL_accelerate'

[WARNING: warnings.py:  109]: /usr/local/lib/python3.10/dist-packages/glfw/__init__.py:917: GLFWError: (65550) b'X11: Failed to open display :109'

  warnings.warn(message, GLFWError)


[ERROR] Could not init glfw! 

Do you have any ideas about that? I already tried:

• xvfb-run -a /app/fsqc/run_fsqc [...]
• xvfb-run --auto-servernum --server-num=1 /app/fsqc/run_fsqc [...]
• --bind /tmp/.X11-unix:/tmp/.X11-unix
• --bind /tmp:/tmp

But no success. What actually works is installing xvfb on the host machine and use xvfb-run for the singularity command:

xvfb-run -a singularity exec \
    -B "$subject_dir":/data \
    -B "$out_dir":/out \
    "$sif_file" \
 /app/fsqc/run_fsqc \
[...]

From what I've understood of the concept (I'm not very familar with xvfb-run), xvfb-run should also be able to run inside the container, allowing you to run everything on a headless server without root privileges, right?

Perhaps it's a configuration or permissions issue on my end?

Anyway, the new version has solved the problem for me for now (as long as I use the pip installation or start the singularity container with xvfb-run) - Thank you very much!

[kdiers]

Hello, thanks for the feedback, this is very helpful and good to know. I can confirm that xvfb is present within the image, and that -- as you write -- it should be able to run inside the container. I have checked it one more time today.

So, it's a bit difficult at the moment to tell what could be the source of the issue -- the xvfb options you tried make sense to me. As soon as we have more insight, we'll update here and/or the documentation.

[m-reuter]

Note, our servers have GPUs installed and the NVIDIA driver on the host, maybe that's why the OpenGL stuff is missing in this case and not in our setting.