Traceback training custom dataset

[briancantwe]

Hello! I've gone through the examples and am now setting up my own data for training. I believe I've followed all conventions and steps, but I get this traceback when I try to train:

evc -c configs/exps/l3mhet/l3mhet_testdata.yaml -t train
2024-01-25 08:09:29.854112 easyvolcap.scripts.main -> preflight: Starting experiment: l3mhet_svr_punch, command: main.py:80
                           train
2024-01-25 08:09:30.411467 easyvolcap.utils.console_utils -> inner: Runtime exception: 0-dimensional   console_utils.py:341
                           array given. Array must be at least two-dimensional

LinAlgError: 0-dimensional array given. Array must be at least two-dimensional
*** 0-dimensional array given. Array must be at least two-dimensional
> /home/proclocal/miniconda3/envs/easyvolcap/lib/python3.11/site-packages/numpy/linalg/linalg.py(206)_assert_stacked_2d(
    204     for a in arrays:
    205         if a.ndim < 2:
--> 206             raise LinAlgError('%d-dimensional array given. Array must be '
    207                     'at least two-dimensional' % a.ndim)
    208
    

Any ideas what I might be doing wrong?

Thanks!

[briancantwe]

Ah! It appears that the camera numbering must not have an numbers missing and must start at 01?

[dendenxu]

Hi @briancantwe thanks for using our code!
When the debugger opens up, you can type w and hit ENTER to print a full stacketrace to locate the origin of the error. Could you rerun and paste the results here?

[dendenxu]

Ah! It appears that the camera numbering must not have an numbers missing and must start at 01?

There's no hard limit on the camera numbering or naming. But the directories inside the images folder and the cameras names inside intro.yml and extra.yml should match up.

[briancantwe]

Thank you. I got past this point as it was an issue with my camera names matching up. The actual numbering didn't affect it.

Question though. No separate debugger opens for me though. Am I missing an option?

[dendenxu]

Glad to hear!
About the debugger, by default a pdbr session will be opened to perform post_mortem on the exception as long as we're not in a multi-process environment (e.g. during multi-process data loading and distributed multi-gpu training). It could be because that your exception was thrown in the __getitem__ section of VolumetricVideoDataset.
If you could locate the exact line where the exception was thrown, the mistery should be solved.