MIC-DKFZ / nnUNet

Apache License 2.0
5.91k stars 1.76k forks source link

Title: KeyError: '1' #2442

Open skgtohn opened 3 months ago

skgtohn commented 3 months ago

I am encountering a KeyError: '1' during the preprocessing phase (nnUNetv2_plan_and_preprocess -d DATASET_55 --verify_dataset_integrity) using nnU-Net. to my own dataset (test with the single patient dataset). This error arises when the script attempts to access normalization parameters for the second channel (T1) in the foreground_intensity_properties_per_channel dictionary.

So below is the dataset json file I used. {

"channel_names": {
    "0": "FLAIR",
    "1": "T1",
    "2": "T1gd",
    "3": "T2"
},
"labels": {
    "background": 0,
    "non_enhancing_tumor": 1,
    "edema": 2
},
"numTraining": 1,
"file_ending": ".nii.gz",
"name": "MyDataset",
"reference": "YourReference",
"release": "1.0",
"licence": "none",
"description": "This is a single dataset for nnU-Net."

}

And the input file in the name imagesTr (TASK_055_0000.nii.gz TASK_055_0001.nii.gz TASK_055_0002.nii.gz TASK_055_0003.nii.gz) with the label file TASK_055.nii.gz in the labelsTr.

Error Details: The error occurs in the DefaultPreprocessor class, specifically in the _normalize method.

It seems that the dictionary expected to contain normalization parameters for each channel (foreground_intensity_properties_per_channel) does not have an entry for the key '1', even though the dataset is properly configured with images for each modality. And my understanding is that dtaset.json setup specifies the channels and their types but does not need to explicitly define how each should be normalized as it will automate.

I am looking for guidance on ensuring that foreground_intensity_properties_per_channel is correctly initialized and populated for each channel, particularly for the T1 modality. Any insights on common pitfalls or additional configuration steps that might be required to ensure all modalities are correctly recognized and processed during the nnU-Net preprocessing phase?

Many thanks!

TaWald commented 1 week ago

Please provide the stack trace. It is very helpful in understanding where problems actually arise.

Generally the channel naming only needs to know if a input Is a CT or not because CT Is handled differently than other images. Aside from this I am not aware that there should be an issue with normalization with that name.

Also share the respective plans.json please because the plans holds which modality is supposed to be normalized in which way (which may be missing and the issue?)