QC Failures: Nifty Header & Sequence Support

[m-reuter]

          I made the changes to --user 1001:1001 and it kinda worked but now I have error "FastSurfer asegdkt segmentation failed".

C:\Windows\System32>docker run -v C:/Users/Ernes/my_mri_data:/data -v C:/Users/Ernes/my_fastsurfer_analysis:/output -v C:/Users/Ernes/my_fs_license_dir:/fs_license --rm --user 1001:1001 deepmi/fastsurfer:cpu-latest --fs_license /fs_license/license.txt --t1 /data/subjectX/H1.nii.gz --device cpu --sid subjectX --sd /output --parallel
Version: 2.2.0+9f37d02
Sun Jan 14 08:23:58 UTC 2024

python-s /fastsurfer/FastSurferCNN/run_prediction.py --t1 /data/subjectX/H1.nii.gz --asegdkt_segfile /output/subjectX/mri/aparc.DKTatlas+aseg.deep.mgz --conformed_name /output/subjectX/mri/orig.mgz --brainmask_name /output/subjectX/mri/mask.mgz --aseg_name /output/subjectX/mri/aseg.auto_noCCseg.mgz --sid subjectX --seg_log /output/subjectX/scripts/deep-seg.log --vox_size min --batch_size 1 --viewagg_device auto --device cpu
[INFO: run_prediction.py: 546]: Checking or downloading default checkpoints ...
[INFO: common.py: 111]: Using device: cpu
[INFO: run_prediction.py: 234]: Running view aggregation on cpu
[INFO: inference.py: 200]: Loading checkpoint /fastsurfer/checkpoints/aparc_vinn_coronal_v2.0.0.pkl
[INFO: inference.py: 200]: Loading checkpoint /fastsurfer/checkpoints/aparc_vinn_sagittal_v2.0.0.pkl
[INFO: inference.py: 200]: Loading checkpoint /fastsurfer/checkpoints/aparc_vinn_axial_v2.0.0.pkl
[INFO: common.py: 820]: Single subject with absolute file path for input.
[INFO: common.py: 833]: No subjects directory specified, but the parent directory of the output file /output/subjectX/mri/aparc.DKTatlas+aseg.deep.mgz is 'mri', so we are assuming this is the 'mri' folder in the subject directory.
[INFO: common.py: 875]: Analyzing single subject /data/subjectX/H1.nii.gz
[INFO: common.py: 970]: Output will be stored in Subjects Directory: /output
[INFO: run_prediction.py: 310]: Successfully loaded image from /data/subjectX/H1.nii.gz.
[INFO: run_prediction.py: 418]: Output image directory 001.mgz does not exist. Creating it now...
Traceback (most recent call last):
File "/fastsurfer/FastSurferCNN/run_prediction.py", line 561, in
for subject, (orig_img, data_array) in iter_subjects:
File "/fastsurfer/FastSurferCNN/run_prediction.py", line 462, in pipeline_conform_and_save_orig
yield subject, self.conform_and_save_orig(subject)
File "/fastsurfer/FastSurferCNN/run_prediction.py", line 316, in conform_and_save_orig
if not conf.is_conform(
File "/fastsurfer/FastSurferCNN/data_loader/conform.py", line 625, in is_conform
iaffine = img.affine[0:3, 0:3] - LIA_affine * (
ValueError: operands could not be broadcast together with shapes (3,3) (4,)
ERROR: FastSurfer asegdkt segmentation failed.

Originally posted by @KontorErnestKissi in #428 (comment)

[m-reuter]

what resolution (voxel sizes and dimensions) is your subjectX/H1.nii.gz image? With FreeSurfer you could run mri_info on this and post the result.

In your case the izoom seems to be 4 dimensional, a normal image should only have three dimensions.

FastSurfer/FastSurferCNN/data_loader/conform.py

Line 626 in bed50c3

conformed_vox_size if is_correct_vox_size else izoom

[KontorErnestKissi]

INFO: using NIfTI-1 qform
Volume information for H1.nii.gz
type: nii
dimensions: 192 x 192 x 160
voxel sizes: 1.250000, 1.250000, 1.249826
type: SHORT (4)
fov: 240.000
dof: 1
xstart: -120.0, xend: 120.0
ystart: -120.0, yend: 120.0
zstart: -100.0, zend: 100.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 = 1.0000, z_a = 0.0000, c_a = 1.2500
: x_s = 0.0000, y_s = 0.0000, z_s = 1.0000, c_s = 1.2498
Orientation : RAS
Primary Slice Direction: axial

voxel to ras transform:
1.2500 0.0000 0.0000 -120.0000
0.0000 1.2500 0.0000 -118.7500
0.0000 0.0000 1.2498 -98.7363
0.0000 0.0000 0.0000 1.0000

[m-reuter]

Hmm, that looks OK to me. Strange. We can take a closer look at the code on Monday. We may need to ask for an example image (can be completely zero, just the header should be the same as this one and it should also fail for you at the same place). That could help for debugging this.

In the meantime, you can try running free surfers mri_convert H1.nii.gz H1.mgzand then passing the mgz into fastsurfer. Or directly using FreeSurfer to conform the image mri_convert -c H1.nii.gz H1-conform.mgz

[KontorErnestKissi]

Thank you for your prompt response. I appreciate it.
I tried this one : mri_convert -c H1.nii.gz H1-conform.mgz and it worked . But it has been 6 hours now and it is not done running .

I thought it was supposed to take 60-90 mins for surface reconstruction.This is where it has run to and it has been there since:

RUNNING HEMIs in PARALLEL !!!

RunBatchJobs: Logfile: /output/subjectX/scripts/recon-surf.log
RunBatchJobs: CMDF: /output/subjectX/scripts/lh.processing.cmdf
RunBatchJobs: CMDF: /output/subjectX/scripts/rh.processing.cmdf
Waiting for PID 1282 of (1282 1285) to complete...

[dkuegler]

It should finish way faster than 6 hours.
Can you attach all files in C:/Users/Ernes/my_fastsurfer_analysis/subjectX/scripts/ ?
This should have the relevant log files for us to see what is going on. Alternatively, remove the --parallel from your command and that then puts all outputs in the command line. But again, that is different and "new issue".

Maybe this has something to do with the fact that this image is >1.0mm in all directions?

what is definitely a bit weird is np.max(np.abs(izoom - conformed_vox_size) < eps) the brackets seem off... it should be np.max(np.abs(izoom - conformed_vox_size)) < eps.

But that does not change the fact, that very likely nibabel returns 4 values in img.header.get_zooms(). And that specific error we will only be able to debug if we have the exact same header as it is unclear, if that is a bug in nibabel or FastSurfer.

[KontorErnestKissi]

These are the files:
build.log
build-stamp.txt
deep-seg.log
defect2seg.log
lastcall.build-stamp.txt
patchdir.txt
ponscc.cut.log
recon-all.log
recon-all-status.log
recon-surf.log
unknown-args.txt

[dkuegler]

There is something happening in the right hemisphere: The first fail seems to be in spherical_project.py.
From recon-surf.log:

Command python-s /fastsurfer/recon_surf/spherically_project.py -i /output/subjectX/surf/rh.smoothwm.nofix -o /output/subjectX/surf/rh.qsphere.nofix failed.

I'll talk about this with @m-reuter tomorrow.

[dkuegler]

As for the original error that is at the top of the issue: I think we need your header (from your image) to reproduce that error...
If you are able to share that original H1.nii.gz file, please get in touch via email. I don't partricularly know how to make sure you will send the exact header otherwise. Many other conversion tools might modify the header (as mri_info does not seem to have the issue with the four dimensions).

[KontorErnestKissi]

You can find the image file below:
deleted

Thank you .

[dkuegler]

I have received the file, I will take a look tomorrow. I also removed the link from your post so this file does not leak into the general public.

[KontorErnestKissi]

Thank you very much.

[dkuegler]

I had a look at the file you provided and it is not oriented as the header suggests.
Overall, the headers seem pretty inconsistent to even corrupted.

I think the header says the image is stored as RAS, while in fact it might be stored as LIA.

[m-reuter]

When opening the image in FreeView it is not oriented correctly but flipped. This indicates a corrupt header. Furthermore, the image is 4D but with a single frame (so the 4th dimension has size 1). That is also unusual. Probably something went wrong when converting this image from DICOM to nifti?

The failure later in the pipeline and the long runtime are probably caused by the incorrect orientation.