New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeError: list indices must be integers or slices, not str #1213
Comments
Running debugging mode, the issue arrives here: ivadomed/ivadomed/transforms.py Line 719 in 9bb4e7f
Inspecting the variables:
|
Interestingly there is no "str":
|
Ah! wait, the error stems from the call to:
Because |
From #815, the culprit was the presence of the field "NumpyToTensor" in the data augmentation, which is indeed listed in my original config file (#1213 (comment)). However, I tried with another config file, based on the latest ivadomed version, and I still observe the error. More recent config file{
"command": "train",
"gpu_ids": [4],
"path_output": "model_seg_lesion_mp2rage_",
"model_name": "model_seg_lesion_mp2rage",
"debugging": true,
"object_detection_params": {
"object_detection_path": null,
"safety_factor": [1.0, 1.0, 1.0]
},
"wandb": {
"wandb_api_key": "9095e2bc9e4ab445d478c9c8a81759ae908be8c6",
"project_name": "basel-mp2rage-lesion",
"group_name": "my_group",
"run_name": "run-3",
"log_grads_every": 100
},
"loader_parameters": {
"path_data": ["/Users/julien/temp/model_seg_basel/data_processed_lesionseg_small"],
"subject_selection": {"n": [], "metadata": [], "value": []},
"target_suffix": ["_lesion-manual", "_lesion-manual3"],
"extensions": [".nii.gz"],
"roi_params": {
"suffix": null,
"slice_filter_roi": null
},
"contrast_params": {
"training_validation": ["UNIT1"],
"testing": ["UNIT1"],
"balance": {}
},
"slice_filter_params": {
"filter_empty_mask": false,
"filter_empty_input": true
},
"slice_axis": "axial",
"multichannel": false,
"soft_gt": false,
"bids_validate": true
},
"split_dataset": {
"fname_split": null,
"random_seed": 42,
"split_method" : "participant_id",
"data_testing": {"data_type": null, "data_value":[]},
"balance": null,
"train_fraction": 0.6,
"test_fraction": 0.2
},
"training_parameters": {
"batch_size": 4,
"loss": {
"name": "DiceLoss"
},
"training_time": {
"num_epochs": 50,
"early_stopping_patience": 50,
"early_stopping_epsilon": 0.001
},
"scheduler": {
"initial_lr": 0.001,
"lr_scheduler": {
"name": "CosineAnnealingLR",
"base_lr": 1e-5,
"max_lr": 1e-3
}
},
"balance_samples": {
"applied": false,
"type": "gt"
},
"mixup_alpha": null,
"transfer_learning": {
"retrain_model": null,
"retrain_fraction": 1.0,
"reset": true
}
},
"default_model": {
"name": "Unet",
"dropout_rate": 0.3,
"bn_momentum": 0.1,
"final_activation": "sigmoid",
"depth": 3
},
"FiLMedUnet": {
"applied": false,
"metadata": "contrasts",
"film_layers": [0, 1, 0, 0, 0, 0, 0, 0, 0, 0]
},
"Modified3DUNet": {
"applied": true,
"length_3D": [32, 64, 128],
"stride_3D": [32, 64, 128],
"attention": false,
"n_filters": 8
},
"uncertainty": {
"epistemic": false,
"aleatoric": false,
"n_it": 0
},
"postprocessing": {
"remove_noise": {"thr": -1},
"keep_largest": {},
"binarize_prediction": {"thr": 0.5},
"uncertainty": {"thr": -1, "suffix": "_unc-vox.nii.gz"},
"fill_holes": {},
"remove_small": {"unit": "vox", "thr": 3}
},
"evaluation_parameters": {
"target_size": {"unit": "vox", "thr": [20, 100]},
"overlap": {"unit": "vox", "thr": 3}
},
"transformation": {
"Resample":
{
"hspace": 1,
"wspace": 1,
"dspace": 1
},
"CenterCrop": {
"size": [32, 64, 128]},
"RandomAffine": {
"degrees": 10,
"scale": [0.2, 0.2, 0.2],
"translate": [0.2, 0.2, 0.2],
"applied_to": ["im", "gt"],
"dataset_type": ["training"]
},
"ElasticTransform": {
"alpha_range": [28.0, 30.0],
"sigma_range": [3.5, 4.5],
"p": 0.1,
"applied_to": ["im", "gt"],
"dataset_type": ["training"]
},
"NormalizeInstance": {"applied_to": ["im"]}
}
}
|
Based on #830, old config files with the "NympyToTensor" key are supposed to be retrocompatible, so I don't think this is the issue here. |
Thanks @jcohenadad for reporting this issue. I was able to reproduce the error with a 3D training.
I have little experience with 3D training and transforms, so I don't know why there is a difference between 2D and 3D. I'll continue the investigation to find a fix and evaluate the implications, but it may take some time. Note that the same error happens for other transforms, for example, if I switch the order of "RandomAffine" and "ElasticTransform", I get the same error for elastic transforms here: ivadomed/ivadomed/transforms.py Line 899 in 9bb4e7f
The only work around I have at this moment is to do the training without data augmentations i.e. without "RandomAffine" and "ElasticTransform" in this case. |
As a side note, we should make sure to add a test with the fix so we can catch this in the future. |
Thank you very much for the excellent detective work @mariehbourget 🙏 . I'm surprised this hasn't been caught before. |
Seems like more testing with 3D test pathway will be required. I will make a note to test that part as well in the Loader V2. |
Ok, I found where this is happening! In short:
The bug is fairly recent and was introduced in PR #1169 in July.
As I said, the fix should be simple, but I will require some time to test it properly in different scenarios (2D/3D, single/multi-channel and single/multi-rater). |
Issue description
Terminal output (from Wandb): output.log
log: log.log
version_info.log
Config file
Possibly related to #815
The text was updated successfully, but these errors were encountered: