Fastsurfer crops the image volumes

[rohitrango]

Description

Hi there! Thank you for releasing the library! I'm trying to use the seg_only functionality to get the DKT atlas labels, but my segmentations etc. are cropped and way off to the side. The image is a regular T1w image with 1mm isotropic resolution.

Here is my original image (viewed in ITK SNAP):

Here is the command I'm running:

./run_fastsurfer.sh --sid results --sd /data/sub01/fastsurfer --t1 /data/sub01/aligned_norm.nii.gz --seg_only --no_cc --no_cereb --no_hypothal --threads 8

Here is the orig.mgz (conformed input - notice the crop)

Here is the orig.mgz with segmenation overlaid

Expected Behavior

There should be no cropping in the final results.

Environment

• local install and uv

[rohitrango]

I think I figured it out. In the crop_transform function, the offsets should be negative of what they are! I don't know if this function is checked or not, but simply adding

offsets = [-x for x in offsets]

before calling _crop_transform_make_indices conforms the image correctly (and visualization of the conformed image and subsequent segmentation also matches with ITK-SNAP)

[m-reuter]

Thanks for reporting. Either there is something wrong in the header of your image or ( more likely) it is a bug . I assume you use the dev branch and not our stable release?

[rohitrango]

I think it is the former because I ran the pipeline on a few other datasets and in those datasets I did not encounter the same problem. I'm still unsure what might be causing this.

The offending datum in this case is from the neurite-OASIS dataset https://github.com/adalca/medical-datasets/blob/master/neurite-oasis.md

[m-reuter]

And did you use the current dev or did this (also) happen in stable?

Also, don't use skull striped images as input, it needs the full head image.

And you use the aligned_norm which they reslice to some template space. Maybe that's where the error happens. Better use the original image or the conformed orig.mgz . Does it also happen there?

[rohitrango]

this is all in the dev branch

re: using skull stripped images - thanks for letting me know! I will re-run the scripts

I did use the aligned_norm, and its metadata does not seem to the incorrect (ITK-SNAP labels A/P, S/I, L/R correctly). The script also seems to use the conformed orig.mgz but I checked and the conformed image itself has the cropping artifact.

I will report the result on the original images to see if they make a difference.

[dkuegler]

Can you send us the mri_info output when you pass the input images?
The only thing that really makes sense to me is if the images are zero-padded to a size larger than 256 (I do not know why you would want to do this, but this would results in this type of image).
Also, I have recently seen a similar offset in a different dataset, but it was nowhere as close as this and I attributed it to bad padding... We will see, if we can reproduce this error if you find it persists.

[rohitrango]

Here it is

Volume information for aligned_norm.nii.gz
          type: nii
    dimensions: 160 x 192 x 224
   voxel sizes: 1.000000, 1.000000, 1.000000
          type: FLOAT (3)
           fov: 160.000
           dof: 1
        xstart: -80.0, xend: 80.0
        ystart: -96.0, yend: 96.0
        zstart: -112.0, zend: 112.0
            TR: 0.00 msec, TE: 0.00 msec, TI: 0.00 msec, flip angle: 0.00 degrees
       nframes: 1
       PhEncDir: UNKNOWN
       FieldStrength: 0.000000
ras xform present
    xform info: x_r =  -1.0000, y_r =   0.0000, z_r =   0.0000, c_r =     0.0000
              : x_a =   0.0000, y_a =   0.0000, z_a =   1.0000, c_a =     0.0000
              : x_s =   0.0000, y_s =  -1.0000, z_s =   0.0000, c_s =     0.0000
Orientation   : LIA
Primary Slice Direction: coronal

voxel to ras transform:
               -1.0000   0.0000   0.0000    80.0000
                0.0000   0.0000   1.0000  -112.0000
                0.0000  -1.0000   0.0000    96.0000
                0.0000   0.0000   0.0000     1.0000

voxel-to-ras determinant -1

ras to voxel transform:
               -1.0000  -0.0000  -0.0000    80.0000
               -0.0000  -0.0000  -1.0000    96.0000
               -0.0000   1.0000  -0.0000   112.0000
               -0.0000  -0.0000  -0.0000     1.0000

also attaching a sample volume here
test.nii.gz

[dkuegler]

I had a look at both the images and the segmentations generated by FastSurfer 2.4.2 from these files. They look fine to me and are placed in appropriate positions in freeview.

The dev FastSurfer on the other hand does produce out-of-view predictions -- and orig files -- for "aligned" image files.

This is likely due to changes in the conform script and the fact that the conformed position of these files is "interesting".

[rohitrango]

thanks for looking into this!