How to handle SUMA_SigForFWHM error when using small target FWHM in SurfSmooth?

AFNI Message Board
1

Hello,

I am analyzing high-resolution fMRI data, and would like to apply a small FWHM (e.g., 1.5 mm or 1.0 mm) using SurfSmooth with -target_fwhm option to preserve spatial resolution as much as possible.

Thus, I ran this command for smoothing.


    SurfSmooth                      \
        -spec "${spec_file}"        \
        -surf_A smoothwm            \
        -input  "${input_data}"     \
        -met HEAT_07                \
        -target_fwhm "${smoothing_val}"    \
        -blurmaster "${errts_file}" \
        -no_detrend_master          \
        -output "${output_filename}"

However, this error message was shown:

--     Error SUMA_SigForFWHM (SUMA_GeomComp.c:7363):
FWHM desired (1.500) is too small relative to average intersegment length (AvgLe = 0.753).
Expecting a ration of FWHM/AvgLe >= 2.0
The automatic sigma selection is poor for this FWHM/AvgLe of 1.990738.
You can set sigma manually instead.
--     Error SurfSmooth (SUMA_SurfSmooth.c:2204):
Failed to get decent sigma (-1.000000)

To solve this error, can I simply set a manual sigma with -sigma option of SurfSmooth?
Or, does the constraint FWHM/AvgLe >= 2.0 mean that my FWHM value for -target_fwhm was too small, and I should set a larger target FWHM with the -target_fwhm?

I am using this AFNI version:

Precompiled binary macos_13_ARM: Sep 17 2025 (Version AFNI_25.2.13 'Gordian I')

Thank you in advance.

-Nori

2

Hi Nori,

Maybe your anatomical datasets are higher resolution, but the surfaces in question are not. That average edge length seems reasonably normal for a FreeSurfer output, std.141, say. And those edges are barely too long for a 1.5 mm FWHM, and much too long for 1.0 mm.

I am not so on top of FreeSurfer - is there a way to get higher resolution surfaces from higher resolution data?

And to be sure, *is* the original resolution high?

Thanks,

-rick

3

Hi, rick

Thank you for the quick and helpful response.

As you pointed out, my anatomical data is standard resolution, while the fMRI data is high resolution.

My fMRI data is 0.75 mm isotropic, but the anatomical data is 1.0 mm isotropic, acquired on a different scanner due to experimental limitations.

So, it may be difficult to get higher resolution surfaces directly from FreeSurfer, because I unfortunately don't have higher resolution anatomical data that matches the fMRI resolution.

I would appreciate any advice or recommendations on how to handle this resolution mismatch issue.

Thank you in advance.

--Nori

4

Hi Nori,

It is good to keep this anatomical limitation in mind. Any operations on the surface will effectively be as if the data were slightly lower resolution. Assuming you are running @SUMA_Make_Spec_FS, it should be possible to get a higher resolution output from there, such as asking for an additional surface with perhaps twice the nodes:

@SUMA_Make_Spec_FS ... -ld 60 141 200 ...

On the plus side, this should allow for the lower blurring (going down to FWHM=1 seems too small to even try with these surfaces, but 1.5 seems reasonable). On the minus side, it is akin to using 3dresample to oversample a volumetric dataset. It won't actually add information to the analysis. But it should at least allow passing the restriction that you are right on the edge with.

We could also make the SurfSmooth restriction slightly less. But that might be less predictable, and I would worry about unexpected side effects.

Does that seem reasonable?

-rick

5

Two things to add to @rickr's response:

  1. the @SUMA_Make_Spec_FS ... -ld 60 141 200 ... is likely the easiest way to go.

  2. If that doesn't work: I think you could, instead of -target_fwhm, use -Niter and -fwhm (direct blur specification) rather than asking SurfSmooth to solve for the iteration count itself. This sidesteps the SigForFwhm estimation step entirely.

  3. Worth sanity checking with SurfFWHM beforehand to verify that you can even get a specific level of smoothness to the data.

-Peter

6

Hi, Rick and Peter.

Thank you very much for the helpful advice, especially for considering my data limitations.

Using @SUMA_Make_Spec_FS with the -ld option sounds very reasonable for me.

I understand that using a higher -ld acts as an oversampling step, but it seems like the best approach to try first for my data.

Additionally, if that does not work, I will try the approach that Peter suggested.

Thanks again for your support!

-Nori