Dear developers,
The new version of tedana package (https://tedana.readthedocs.io/en/latest/usage.html) should produce diagnostic plots when requested. However, when it starts to create the plots, it prints out an error that refers to axis limits (see the end of the message).
Could you let me know what the issue may be? I included some sample images and a simplified snippet of code that I used for calling tedana here:
https://uoe-my.sharepoint.com/:f:/g/personal/atamm2_ed_ac_uk/Eti2kifyq7tOsopHxKE7qfIBJXN7csy1H0CtiHkZa3ZHlA?e=5bEs4W
I installed tedana in a Python virtual environment (Python 3.5) on a computer cluster. For these images, tedana converged in less than 250 iterations. I ran tedana inside a mask that combined an EPI mask with grey and white matter mask (this is because the EPI mask alone left out some parts of the temporal lobes).
Many thanks for your help,
Andres
Andres Tamm
Research Assistant
Department of Psychology
University of Edinburgh
The error message (’/X’ refers to a path to my personal folder):
INFO:tedana.workflows.tedana:Making figures folder with static component maps and timecourse plots.
/X/tedana-venv/lib/python3.5/site-packages/numpy/fft/helper.py:226: RuntimeWarning: divide by zero encountered in double_scalars
val = 1.0/(n*d)
/X/tedana-venv/lib/python3.5/site-packages/numpy/fft/helper.py:229: RuntimeWarning: invalid value encountered in multiply
return results * val
Traceback (most recent call last):
File “/X/tedana-venv/bin/tedana”, line 10, in
sys.exit(_main())
File “/X/tedana-venv/lib/python3.5/site-packages/tedana/workflows/tedana.py”, line 453, in _main
tedana_workflow(**vars(options))
File “/X/tedana-venv/lib/python3.5/site-packages/tedana/workflows/tedana.py”, line 435, in tedana_workflow
png_cmap=png_cmap)
File “/X/tedana-venv/lib/python3.5/site-packages/tedana/viz.py”, line 185, in write_comp_figs
ax_fft.set_xlim(freqs[0], freqs[-1])
File “/X/tedana-venv/lib/python3.5/site-packages/matplotlib/axes/_base.py”, line 3227, in set_xlim
left = self._validate_converted_limits(left, self.convert_xunits)
File “/X/tedana-venv/lib/python3.5/site-packages/matplotlib/axes/_base.py”, line 3139, in _validate_converted_limits
raise ValueError(“Axis limits cannot be NaN or Inf”)
ValueError: Axis limits cannot be NaN or Inf
Hey Andres,
That is definitely some strange behavior, haven’t seen it before.
Looks like it is having an issue with a step in the FFT, but I have never seen this before. I only briefly looked through the files you shared, but nothing jumped out at me as being strange. I’ll keep digging and see if I can find anything. Maybe @tsalo or @emdupre can also take a look at some point, though OHBM might be keeping them busy.
-Logan
Alright, as near as I can tell, it looks like the problem is that tedana thinks your TR is zero. This explains the divide by zero when in the FFT steps.
I checked one of the inputs with 3dinfo (AFNI), and it thought your TR was 1 - but when I load that image in with nibabel:
data = "X/rasub-03_task-semantic_run-2_echo-1_bold.nii"
and use the function to find the TR:
data.header.get_zooms()[-1]
it reports zero.
Clearly an issue. If I had to guess, I might say it is because the data appear to be touched by SPM, or maybe just something has gone awry with the header. Mango (another fMRI viewer) also reports a zero TR…so I’m fairly certain this is the issue.
One fix would be allowing the user to enter their own TR at the command line for edge cases like this.
Lemme see what I can do.
Logan
1 Like
Hi Logan,
Thank you very much for your quick reply and help! Before running tedana, I converted the original DICOM images to NIfTI with dcm2niix, and then performed slice timing and motion correction in SPM. I have not yet checked whether TR is correctly saved in the image header of the original untouched images, but I will do so. I also recall that when I ran BIDS validator on my data, it reported an issue with TR being missing from the header. I did not focus much on it then, as I knew that the TR was saved in a separate .json file and thought that this is sufficient.
I will try fixing the issue with TR in the header, and then see whether I can produce the figures with tedana!
Thank you again for your suggestions,
Andres
Hi Andres,
Thanks for reporting this issue! Logan brought it to my attention, and we’re going to potentially implement some new features to help with a case like this where the TR is read as 0. It also seems that there are quite a few people reading the thread, so I thought I would post this link to our new newsletter we’re putting out monthly(ish).
https://tinyletter.com/tedana-devs
That way if we implement a change that addresses this problem you can see it without subscribing to GitHub notifications, which can be overwhelming to people who aren’t actively developing. Feel free to ping me if you have further questions, either here or on GitHub.
Best,
Josh
Hi Logan and Josh,
Thank you again for your quick response and for your openness to discuss these questions further!
I can confirm that after I added the TR to the NIfTI header, tedana produced diagnostics plots just fine. It looks like the TR information got lost from the header after I ran SPM functions on the data.
Many thanks,
Andres