FastSurfer Segmentation Modules: disable conformation of input image to isometric spaces about fastsurfer

[m-reuter]

Hi, no, it can only work on conform, isotropic images. You can choose a different voxel size, but it needs to be isotropic. Also it is not recommended to map to MNI (or other spaces), to avoid yet another interpolation step.

[dkuegler]

If you need segmentations to be in the MNI space because some other analysis is performed there and so you want labels to be defined there, there is currently only one possible procedure that is not well-tested (this would also be similar to what you would/could do with FreeSurfer):

1. make sure your image is at 1mm isotropic (in MNI-space)
2. modify the image to fix the RAS matrix (the matrix needs to be along main directions, ((1 0 0), (0 1 0), (0 0 1)) or ((1 0 0), (0 0 -1), (0 -1 0)) .... or the like.... NOTE: you are intentionally breaking the consistency of RAS-coordinates here.
3. run FastSurfer on the image you created --- the output segmentations will be in the same isotropic image space, ...
4. copy the segmentation files after the completed run (e.g. mri/aseg.mgz and revert your RAS-matrix to what it was before --- this fixes the consistency issue noted in 2. (also note, aseg.mgz is always stored in LIA, you may need to convert it to RAS or whatever you had in step 2 first.)
5. Repeat the step 4 for any other segmentation files

I believe this should get you the outputs you wanted... you still should quality-check everything.

[dkuegler]

As an additional note: the conformation is needed for 2 reasons:

1. The network needs isotropic images and the intensity rescaling to 0-255
2. The FreeSurfer-based surface pipeline needs images to be stored as LIA (RAS matrix only +-1 or 0).

[RudyZhang011022]

Thank you very much for the explanation. Here's a quick follow-up question:
Suppose I set a t1w image that is in 1mm MNI space (pixels are isotropic, but the dimensions of the image are 192 * 220 * 192) as the input for fastsurfer, would the conformation step (which results the output image to be 256 * 256 * 256) change voxel sizes (meaning that each voxel would be streched or compressed) or would the voxels remain the same size (1 milimeter squared) as those from the original 1mm MNI space? I set --vox_size as 1. I am mainly using fastsurfer for tissue volume calculations and I am wondering if there needs a conversion.

[m-reuter]

Hi,

quick answer: it is padding, but voxels size will not be changed again if it is already 1mm isotropic, BUT it will rotate your image.

Just to explain and document this better. FastSurfer follows the FreeSurfer convention (with its advantages and disadvantages).

What the conform step in FreeSurfer (and FastSurfer) does:

• it re-orients the image so that the axes are aligned with the RAS coordinate system (LIA orientation specifically). This is usually a rotation.
• at the same time it re-slices inputs to 1mm isotropic voxels. FastSurfer is a little different here, as it keeps a higher resolution by default if it finds it in the input. FreeSurfer needs a specific hires flag for that and always uses 1mm by default.
• it adjusts image dimension to 256x256x256 (usually by padding) for 1mm and larger cubic images for higher resolutions, to make sure that no part of head is cropped during rotation and re-slicing.
• image intensities are robustly scaled to 0 .. 255, also aiming to normalise WM intensity to around 110
• images are converted to unsigned character data type

This happens to any input image and cannot be switched off. It means, even if your images are already 1mm isotropic, they would still be rotated to the axes (LIA). The only way to prevent it, is to overwrite your image header and pretend that it is already in LIA orientation. Then fix the header again of all outputs. This is a very ugly workaround and can lead to all kinds of issues (e.g. derived surfaces etc are also affected).

We have considered moving away from the FreeSurfer way to allow more flexibility here, but it could have many unintended consequences and will likely produce incompatibilities between FastSurfer and FreeSurfer. It would also require retraining and redesign of all our other deep learning segmentation modules. Lot's of work.

Another workaround could be to not store the hard labels but instead write out the soft-labels (predictions) and map those to the input or talairach space and then convert to hard labels there (this would not help the surface pipeline, but for the segmentation). It would not be optimal but still much better than mapping hard labels with e.g. nearest neighbour interpolation. I am not sure if we have a flag for writing soft labels (which would require a lot disk space), but it could probably be added relatively easily, e.g. as a 4D image stack. We could also have a command line tool that reduces this to a 3D hard segmentation again after mapping. It could even be done in a single step, inside fastsurfer, if requested by the user as we know the original position of your input. We are thinking about these options.