Closed mrikasper closed 5 years ago
Dear Hrvoje,
this was related to an inconsistent setting in the tapas_physio_new()
constructor for the peak detection method. I will fix this in the development branch soon.
Meanwhile, if you specify
physio.preproc.cardiac.initial_cpulse_select.method = 'auto_matched'
in line 21 of your script, it runs through for me (see below).
Also, optionally, you can set
physio.scan_timing.sync.method = 'scan_timing_log';
in line 19 to use the scan onset triggers from the BIDS file itself.
Note besides: The cardiac time course is very clean now, however, the respiratory trace has some weird intermittent structure (e.g., around 110s). Because of that, the peak detection fo RVT computation has some trouble (e.g., at 45s and 60s). I presume this is respiratory belt detachment (you see the heartbeat in these phases though, if you zoom in).
Luckily (surprisingly?), it does not affect the final interpolation of RVT too much, but there would be some manual work necessary to make the peak detection work here. I presume that tightening the template width would be one option, because the faulty parts of the time series always look like an extended exponential decay, where as the true peaks are rather classical spikes.
All the best, Lars
Hi Lars,
thanks for a quick response. Indeed, with 'auto_matched' option everything works out.
Though, if switch physio.scan_timing.sync.method
to scan_timing_log
, I get the following error with some files:
No cardiac R-peak (heartbeat) events provided
Warning: First volume with missing slice events (408: 1 instead of 16 found)
> In tapas_physio_log (line 55)
In tapas_physio_get_onsets_from_locs (line 72)
In tapas_physio_create_scan_timing (line 117)
In tapas_physio_main_create_regressors (line 149)
Warning: Ignoring extra legend entries.
> In legend>set_children_and_strings (line 646)
In legend>make_legend (line 316)
In legend (line 259)
In tapas_physio_get_cardiac_pulse_template (line 209)
In tapas_physio_get_cardiac_pulses_auto_matched (line 55)
In tapas_physio_get_cardiac_pulses (line 87)
In tapas_physio_main_create_regressors (line 169)
maxscan (incl. dummies) = 408
tmin (1st scan start (1st dummy))= 29.82 s
tmin (1st scan start (after dummies))= 29.82 s
tmax = 617.06 s
mean TR = 1.44 s
Error using tapas_physio_get_sample_points (line 45)
scan 229: only 1 slice scan events. Cannot resample to slice 9
Error in tapas_physio_create_retroicor_regressors (line 83)
sample_points = tapas_physio_get_sample_points(ons_secs, sqpar);
Error in tapas_physio_main_create_regressors (line 287)
tapas_physio_create_retroicor_regressors(ons_secs, sqpar, ...
Here are example files: sub-s082.zip
This method I guess uses directly the trigger log, instead of using TR info and starting time? That is probably preferrable option, given some latencies between the machines in this case (separate unit for recording physio data).
Best, Hrvoje
Dear Hrvoje,
this is the trouble with experimental data....every dataset is different. The reason for the scan trigger bug was that for some of the volumes, the scan trigger was "on" for longer than one sample, and my original implementation interpreted this as consecutive volume triggers with a TR of 1 sample (see attached figure: trigger volume index plotted vs duration between triggers in ms).
I fixed this now ignoring too fast trigger events, see this commit in the dev branch.
Good luck, Lars
Right, I noticed that in some of the datasets and wondered whether I should clean it up. For BIDS, it's probably better to leave it in as raw form as possible.
Thanks, Hrvoje
Hi Lars,
I got new data, and this time I collected analog cardiac measurements. If I feed this into PhysIO, with BIDS option I get the following error:
Instead of option
I tried using
as in
tapas_physio_example_siemens_hcp_ppu3t_spm_job.m
.BIDS format allows analog cardiac responses, perhaps you set it up according to my data which had heart beat data instead?
Here are the data files: sub-s080.zip
Hrvoje
Originally posted by @hstojic in https://github.com/translationalneuromodeling/tapas/issues/36#issuecomment-458576039