search

cpp-lln-lab / bidspm

an SPM centric BIDS app
https://bidspm.readthedocs.io/en/latest/general_information.html
GNU General Public License v3.0
5 stars 13 forks source link

[BUG] 'pattern' error during BUILDING JOB: slice timing correction #967

Open JacMatu opened 1 year ago

JacMatu commented 1 year ago

Is there an existing issue for this?

Operating system

Operating system version

SPM 12 version

Platform

Platform version

bidspm version

v3.0.0

bidspm branch / commit number

Expected Behavior

bidspm basic preprocessing called with 

bidspm(bids_dir, output_dir, 'subject', ...
       'participant_label', subject_label, ...
       'action', 'preprocess', ...
       'task', task_label, ...
       'ignore', {'qa'}, ... 
       'space', {'individual', 'IXI549Space'}, ...
       'fwhm', 2);

Current Behavior & Error message

'pattern' requires one of the following:
  Antenna Toolbox
  Communications Toolbox
  Phased Array System Toolbox

Error in getAcquisitionTime (line 28)
                   '\n- slice timing: ' pattern], ...

Error in setBatchSTC (line 66)
  acquisitionTime = getAcquisitionTime(sliceOrder, repetitionTime);

Error in bidsSTC (line 47)
      matlabbatch = setBatchSTC(matlabbatch, BIDS, opt, regexify(subLabel));

Error in bidspm>preprocess (line 251)
      bidsSTC(opt);

Error in bidspm>executeAction (line 142)
      preprocess(args);

Error in bidspm (line 77)
    executeAction(action, args);

Error in step_1_bidspm_preprocess (line 24)
bidspm(bids_dir, output_dir, 'subject', ...

Anything else?

error_2023-03-27T18-10.log

github-actions[bot] commented 1 year ago

Thank you for your issue. Give us a little time to review it.

PS. You might want to check the FAQ if you haven't done so already.

This is an automated reply, generated by FAQtory

Remi-Gau commented 1 year ago

Ok defo a bug but this also means there is something wrong with your slice timing info. Can you send me the json of one of your bold file?

JacMatu commented 1 year ago

Sure, here it is (I'm not sure if it will work via email)

On Mon, 27 Mar 2023 at 19:06, Remi Gau @.***> wrote:

Ok defo a bug but this also means there is something wrong with your slice timing info. Can you send me the json of one of your bold file?

— Reply to this email directly, view it on GitHub https://github.com/cpp-lln-lab/bidspm/issues/967#issuecomment-1485520097, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWQTRS3KWNTKV5IGSF7QDXLW6HCJTANCNFSM6AAAAAAWJMNHDI . You are receiving this because you authored the thread.Message ID: @.***>

-- Ph. D. Laboratory of Brain Imaging (LOBI) Nencki Institute of Experimental Biology Polish Academy of Sciences Pasteur 3, 02-093 Warsaw, Poland Tel: +48 22 5892 551 mail: @. @.> website: http://lobi.nencki.gov.pl/ Google Scholar profile https://scholar.google.com/citations?user=QI1KL4wAAAAJ&hl=pl&oi=ao

Remi-Gau commented 1 year ago

@all-contributors add @JacMatu for bug, userTesting

allcontributors[bot] commented 1 year ago

@Remi-Gau

I've put up a pull request to add @JacMatu! :tada:

JacMatu commented 1 year ago

Hi Remi,

I tried to run the full preprocessing pipeline with fixed issue #967 https://github.com/cpp-lln-lab/bidspm/issues/967 (slice timing errors), and I've encountered new types of errors. I have no idea why it happens, but it looks like some runs of some subjects have different slice timings (e.g. 1 of of 6 runs within subject is different).

Judging by the content of test_getAcquisitionTime.m (bidspm/tests/tests_preproc/utils/) it looks like the slice timings were hard-coded for my sequence and work usually. with values of

[0 0.0575 0.115 0.1725 0.23 0.2875 0.345 0.4025 0.46 0.5175 0.575 0.6325 0.69 0.745 0.8025 0.86 0.9175 0.975 1.0325 1.09 1.1475 1.205 1.2625 1.32 1.3775 1.435 1.4925 1.55 1.6075 1.665 1.7225 1.7775 1.835 1.8925 1.95]

However, sometimes I have a run with slice timing of "SliceTiming": [ 0, 0.0575, 0.115, 0.1725, 0.23, 0.2875, 0.345, 0.4025, 0.46, 0.5175, 0.575, 0.6325, 0.69, 0.7475, 0.805, 0.8625, 0.92, 0.9775, 1.0325, 1.09, 1.1475, 1.205, 1.2625, 1.32, 1.3775, 1.435, 1.4925, 1.55, 1.6075, 1.665, 1.7225, 1.78, 1.8375, 1.895, 1.9525 ],

Which is slightly off and causes errors. I have no idea why it happened since everything was run with an identical protocol... See error log and example jsons attached.

I'm tempted to skip slice timing for now if it's something complicated to fix. If I were to do this, I assumed that it could be done via

opt.stc.skip = 0, ;

changed to 1, but I'm not sure how to access opt from the script level.

Best,

Jacek

On Wed, 29 Mar 2023 at 10:27, Remi Gau @.***> wrote:

Closed #967 https://github.com/cpp-lln-lab/bidspm/issues/967 as completed via #969 https://github.com/cpp-lln-lab/bidspm/pull/969.

— Reply to this email directly, view it on GitHub https://github.com/cpp-lln-lab/bidspm/issues/967#event-8873399576, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWQTRS6L7FNNYGRNGSEGZUDW6PW5NANCNFSM6AAAAAAWJMNHDI . You are receiving this because you authored the thread.Message ID: @.***>

-- Ph. D. Laboratory of Brain Imaging (LOBI) Nencki Institute of Experimental Biology Polish Academy of Sciences Pasteur 3, 02-093 Warsaw, Poland Tel: +48 22 5892 551 mail: @. @.> website: http://lobi.nencki.gov.pl/ Google Scholar profile https://scholar.google.com/citations?user=QI1KL4wAAAAJ&hl=pl&oi=ao

JacMatu commented 1 year ago

Sorry forgot to attach the files

On Tue, 18 Apr 2023 at 16:01, Jacek Matuszewski @.***> wrote:

Hi Remi,

I tried to run the full preprocessing pipeline with fixed issue #967 https://github.com/cpp-lln-lab/bidspm/issues/967 (slice timing errors), and I've encountered new types of errors. I have no idea why it happens, but it looks like some runs of some subjects have different slice timings (e.g. 1 of of 6 runs within subject is different).

Judging by the content of test_getAcquisitionTime.m (bidspm/tests/tests_preproc/utils/) it looks like the slice timings were hard-coded for my sequence and work usually. with values of

[0 0.0575 0.115 0.1725 0.23 0.2875 0.345 0.4025 0.46 0.5175 0.575 0.6325 0.69 0.745 0.8025 0.86 0.9175 0.975 1.0325 1.09 1.1475 1.205 1.2625 1.32 1.3775 1.435 1.4925 1.55 1.6075 1.665 1.7225 1.7775 1.835 1.8925 1.95]

However, sometimes I have a run with slice timing of "SliceTiming": [ 0, 0.0575, 0.115, 0.1725, 0.23, 0.2875, 0.345, 0.4025, 0.46, 0.5175, 0.575, 0.6325, 0.69, 0.7475, 0.805, 0.8625, 0.92, 0.9775, 1.0325, 1.09, 1.1475, 1.205, 1.2625, 1.32, 1.3775, 1.435, 1.4925, 1.55, 1.6075, 1.665, 1.7225, 1.78, 1.8375, 1.895, 1.9525 ],

Which is slightly off and causes errors. I have no idea why it happened since everything was run with an identical protocol... See error log and example jsons attached.

I'm tempted to skip slice timing for now if it's something complicated to fix. If I were to do this, I assumed that it could be done via

opt.stc.skip = 0, ;

changed to 1, but I'm not sure how to access opt from the script level.

Best,

Jacek

On Wed, 29 Mar 2023 at 10:27, Remi Gau @.***> wrote:

Closed #967 https://github.com/cpp-lln-lab/bidspm/issues/967 as completed via #969 https://github.com/cpp-lln-lab/bidspm/pull/969.

— Reply to this email directly, view it on GitHub https://github.com/cpp-lln-lab/bidspm/issues/967#event-8873399576, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWQTRS6L7FNNYGRNGSEGZUDW6PW5NANCNFSM6AAAAAAWJMNHDI . You are receiving this because you authored the thread.Message ID: @.***>

-- Ph. D. Laboratory of Brain Imaging (LOBI) Nencki Institute of Experimental Biology Polish Academy of Sciences Pasteur 3, 02-093 Warsaw, Poland Tel: +48 22 5892 551 mail: @. @.> website: http://lobi.nencki.gov.pl/ Google Scholar profile https://scholar.google.com/citations?user=QI1KL4wAAAAJ&hl=pl&oi=ao

-- Ph. D. Laboratory of Brain Imaging (LOBI) Nencki Institute of Experimental Biology Polish Academy of Sciences Pasteur 3, 02-093 Warsaw, Poland Tel: +48 22 5892 551 mail: @. @.> website: http://lobi.nencki.gov.pl/ Google Scholar profile https://scholar.google.com/citations?user=QI1KL4wAAAAJ&hl=pl&oi=ao

Remi-Gau commented 1 year ago

I think you will need to drop the log manually in the github windows and not just by email.

Also if you have several runs with different slice timing values:

Remi-Gau commented 1 year ago

send me the log in any case

Remi-Gau commented 1 year ago

bidspm should throw a warning and I wonder if SPM won't crash after that: https://github.com/cpp-lln-lab/bidspm/blob/b5d8087b8298baadcd0472b4705a6a5b5f8fdfa6/src/bids/getAndCheckSliceOrder.m#L82

JacMatu commented 1 year ago

error_2023-04-18T15-59.log

Remi-Gau commented 1 year ago

thanks can you also send me the bold.json files of a "normal" run and that of a "abnormal" run in terms of slice timing values

JacMatu commented 1 year ago

Ok, I've found even a third set of values, which is extremely puzzling since it was all done with the same protocol. (I'm compressing them since guthub doesn't allow .json files.

Run01 = rare, weird case of "abnormality" Run02 = popular "abnormal" timings Run03 = dominant "normal" timings...

All in the same subject... I used dcm2bids for conversion, I'm not sure if that can cause some issues.

matuszewski_bold_jsons.zip

Remi-Gau commented 1 year ago

Thanks for those. I can try to implement further checks and better error messages in bidspm to catch those inconsistencies. I could also try to implement the slice timing differently so that it only uses the slice timing value of a given run to process it, instead of assuming that all the runs being preprocessed have the same slice timing values. But I am kinda reluctant to do that because I think that it is valid assumption to make, and that if this assumption is not fullfiled then something is off. what do you think?

JacMatu commented 1 year ago

Absolutely, I see no reason why copied protocol would have different timings between runs and subjects in a random manner. If that would always be the same run# or group then maybe that would be experimentor's / technician's error in setting up the protocol... But this?

I have no idea what's going on...

JacMatu commented 1 year ago

These differences are literally in 0.0025 s, I doubt it will affect the BOLD signal, but it's annoying in the BIDS perfect world...

Remi-Gau commented 1 year ago

at this stage I am more into: if even the scanner sequence are adding some jitter just for fun what hope do we have at reproducible results... 🤷🏾

JacMatu commented 1 year ago

Yeah. I kind of see two solutions for now (to quickly move with the analyses since I want to learn models and mvpa too)

  1. ignore slice timing corrections in the preprocessing - what would be the fastest way with BIDSPM?

  2. change the values in json files, assuming that this is a weird bug. But I really don't want to manually change values in json files, this seems fishy.

JacMatu commented 1 year ago

So the weird thing is that a) bidsvalidator has no issues with differences in jsons regarding the slice timing, not even a warning b) bidspm preprocesses some of the subjects who have single abnormal run without an issue, but spits out errors for others. I'll look into that more tomorrow

Remi-Gau commented 1 year ago

closing for now

reopen or open an new issue if something related reappears

JacMatu commented 1 year ago

Follow up on the issue: 40 subjects in the database 23 had "deviant" slice timings in at least 1 of 6 runs bidspm preprocessing worked for 19 of them without any errors (+ all 17 "standard subjects) error_2023-05-08T22-57.log

Only 4 are left with identical error of Acquisition time cannot be < to any slice timing value.

If I'm not mistaken (I have checked other random "deviant" subjects), this issue might be related to the fact that these subjects have "deviant" values in the run01. I.e., there are other subjects with identical slice timings e.g. in run05 (but their run01 is "typical") and there were no errors during preprocessing. Is it possible that run01 servers as some sort of reference or value check and then everything is assumed to be constant across runs?

Remi-Gau commented 1 year ago

there is kind of something like this: https://github.com/cpp-lln-lab/bidspm/blob/e684f7abd6a752ec2de94afddf95e4a802e31299/src/bids/getAndCheckSliceOrder.m#L70-L88

this checks that all runs have the same slice timing values: so it checks each run against the first one

but what puzzles me is that the error you report happens here: https://github.com/cpp-lln-lab/bidspm/blob/e684f7abd6a752ec2de94afddf95e4a802e31299/src/batches/preproc/setBatchSTC.m#L66

where as the check that all runs have the same values happens before: https://github.com/cpp-lln-lab/bidspm/blob/e684f7abd6a752ec2de94afddf95e4a802e31299/src/batches/preproc/setBatchSTC.m#L56

so if some of your runs have different slice timing, this should have been caught earlier

are you using the lastest version that is on the main branch?

JacMatu commented 1 year ago

No, I'm using the fix-acq_time_error branch from Your remote that you created when I first opened that issue

JacMatu commented 1 year ago

Hi Remi, just to follow up: I've tried to run this analyses with up-to-date main branch bidspm and the error is the same. error_2023-05-12T12-47.log

Remi-Gau commented 1 year ago

Do you have this data somewhere I can check it? On GIN?

JacMatu commented 1 year ago

I have a toy repo which served as a datalad 101 on gin, what do you need? Raw data from 1 subject that is problematic and one that is not? Or something else too?

JacMatu commented 1 year ago

Gin repo should be here https://gin.g-node.org/JacMatu/GIN_TOY_REPO_JM (I've added you as a collaborator), RAW/sub-blind01 is working fine RAW/sub-blind12 produces this error

Sorry it's not a perfect yoda structure, let me know if you need anything else

Remi-Gau commented 1 year ago

that's perfect if I need more I will ping you

Remi-Gau commented 1 year ago

@JacMatu you probably want to make your BIDS dataset valid to avoid being in a world of pain later

Remi-Gau commented 1 year ago

at least add a dataset_description.json: bidspm cannot even start for me even if I use 'skip_validation', false

Remi-Gau commented 1 year ago

In case you are lazy like me, there is a function in bids matlab to create an empty dataset_description.json you can then fill in:

ds_desc = bids.Description();
ds_desc.write(fullfile(pwd, 'GIN_TOY_REPO_JM');
Remi-Gau commented 1 year ago

doing some basic QA

indeed the slice timing values are different for many runs

bids_dir = fullfile(this_dir, '..', 'GIN_TOY_REPO_JM');
BIDS = bids.layout(bids_dir);

%%
subjects = bids.query(BIDS, 'subjects');

%%
clc
for i_sub = 1:numel(subjects)
    meta = bids.query(BIDS, 'metadata', ...
                      'sub', subjects{i_sub}, ...
                      'suffix', 'bold', ...
                      'target', 'SliceTiming');

    values = [];
    equal_to_run_1 = [];
    for i = 1:numel(meta)
        values(:,i) = meta{i};
        equal_to_run_1(:,i) = meta{i} == meta{1}; %#ok<*SAGROW>
    end

    fprintf('\nSliceTiming subject: %s\n', subjects{i_sub})
    disp(values);
    fprintf('\nEqual to run 1\n')
    disp(equal_to_run_1);

end

Gives me:

each columns are the values from one run

the second output for each subject has 1 if the value on a given row is equal to that same value for run 1: in brief ideally it should all be 1 and bidspm should crash if any value is 0

apparently it does not crash for the first subject, so some fixing is required

SliceTiming subject: blind01
         0         0         0         0         0         0
    0.0575    0.0550    0.0575    0.0575    0.0575    0.0575
    0.1150    0.1125    0.1150    0.1150    0.1150    0.1150
    0.1700    0.1700    0.1725    0.1725    0.1725    0.1725
    0.2275    0.2275    0.2300    0.2300    0.2300    0.2300
    0.2850    0.2850    0.2875    0.2875    0.2875    0.2875
    0.3425    0.3425    0.3450    0.3450    0.3450    0.3450
    0.4000    0.4000    0.4025    0.4025    0.4025    0.4025
    0.4575    0.4575    0.4575    0.4600    0.4600    0.4600
    0.5150    0.5150    0.5150    0.5175    0.5175    0.5175
    0.5725    0.5725    0.5725    0.5750    0.5750    0.5750
    0.6300    0.6300    0.6300    0.6325    0.6325    0.6325
    0.6875    0.6875    0.6875    0.6900    0.6900    0.6900
    0.7450    0.7450    0.7450    0.7475    0.7475    0.7475
    0.8025    0.8025    0.8025    0.8025    0.8050    0.8050
    0.8600    0.8600    0.8600    0.8600    0.8625    0.8625
    0.9175    0.9175    0.9175    0.9175    0.9200    0.9175
    0.9750    0.9750    0.9750    0.9750    0.9750    0.9750
    1.0325    1.0300    1.0325    1.0325    1.0325    1.0325
    1.0900    1.0875    1.0900    1.0900    1.0900    1.0900
    1.1450    1.1450    1.1475    1.1475    1.1475    1.1475
    1.2025    1.2025    1.2050    1.2050    1.2050    1.2050
    1.2600    1.2600    1.2625    1.2625    1.2625    1.2625
    1.3175    1.3175    1.3200    1.3200    1.3200    1.3200
    1.3750    1.3750    1.3775    1.3775    1.3775    1.3775
    1.4325    1.4325    1.4325    1.4350    1.4350    1.4350
    1.4900    1.4900    1.4900    1.4925    1.4925    1.4925
    1.5475    1.5475    1.5475    1.5500    1.5500    1.5500
    1.6050    1.6050    1.6050    1.6075    1.6075    1.6075
    1.6625    1.6625    1.6625    1.6650    1.6650    1.6650
    1.7200    1.7200    1.7200    1.7225    1.7225    1.7225
    1.7775    1.7775    1.7775    1.7800    1.7800    1.7800
    1.8350    1.8350    1.8350    1.8350    1.8375    1.8375
    1.8925    1.8925    1.8925    1.8925    1.8950    1.8950
    1.9500    1.9500    1.9500    1.9500    1.9525    1.9500

Equal to run 1
     1     1     1     1     1     1
     1     0     1     1     1     1
     1     0     1     1     1     1
     1     1     0     0     0     0
     1     1     0     0     0     0
     1     1     0     0     0     0
     1     1     0     0     0     0
     1     1     0     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     1     0     0
     1     1     1     1     0     0
     1     1     1     1     0     1
     1     1     1     1     1     1
     1     0     1     1     1     1
     1     0     1     1     1     1
     1     1     0     0     0     0
     1     1     0     0     0     0
     1     1     0     0     0     0
     1     1     0     0     0     0
     1     1     0     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     0     0     0
     1     1     1     1     0     0
     1     1     1     1     0     0
     1     1     1     1     0     1

SliceTiming subject: blind12
         0         0         0         0         0         0
    0.0575    0.0575    0.0550    0.0575    0.0575    0.0575
    0.1150    0.1150    0.1125    0.1150    0.1150    0.1150
    0.1725    0.1725    0.1700    0.1725    0.1725    0.1725
    0.2300    0.2300    0.2275    0.2300    0.2300    0.2300
    0.2875    0.2875    0.2850    0.2850    0.2875    0.2875
    0.3450    0.3450    0.3425    0.3425    0.3450    0.3450
    0.4025    0.4025    0.4000    0.4000    0.4025    0.4000
    0.4600    0.4600    0.4575    0.4575    0.4600    0.4575
    0.5175    0.5175    0.5150    0.5150    0.5175    0.5150
    0.5750    0.5750    0.5725    0.5725    0.5750    0.5725
    0.6325    0.6325    0.6300    0.6300    0.6325    0.6300
    0.6900    0.6900    0.6875    0.6875    0.6900    0.6875
    0.7475    0.7475    0.7450    0.7450    0.7475    0.7450
    0.8050    0.8050    0.8025    0.8025    0.8050    0.8025
    0.8625    0.8600    0.8600    0.8600    0.8600    0.8600
    0.9200    0.9175    0.9175    0.9175    0.9175    0.9175
    0.9775    0.9750    0.9750    0.9750    0.9750    0.9750
    1.0325    1.0325    1.0325    1.0325    1.0325    1.0325
    1.0900    1.0900    1.0875    1.0900    1.0900    1.0900
    1.1475    1.1475    1.1450    1.1475    1.1475    1.1475
    1.2050    1.2050    1.2025    1.2050    1.2050    1.2050
    1.2625    1.2625    1.2600    1.2625    1.2625    1.2625
    1.3200    1.3200    1.3175    1.3175    1.3200    1.3200
    1.3775    1.3775    1.3750    1.3750    1.3775    1.3775
    1.4350    1.4350    1.4325    1.4325    1.4350    1.4325
    1.4925    1.4925    1.4900    1.4900    1.4925    1.4900
    1.5500    1.5500    1.5475    1.5475    1.5500    1.5475
    1.6075    1.6075    1.6050    1.6050    1.6075    1.6050
    1.6650    1.6650    1.6625    1.6625    1.6650    1.6625
    1.7225    1.7225    1.7200    1.7200    1.7225    1.7200
    1.7800    1.7800    1.7775    1.7775    1.7800    1.7775
    1.8375    1.8375    1.8350    1.8350    1.8375    1.8350
    1.8950    1.8925    1.8925    1.8925    1.8925    1.8925
    1.9525    1.9500    1.9500    1.9500    1.9500    1.9500

Equal to run 1
     1     1     1     1     1     1
     1     1     0     1     1     1
     1     1     0     1     1     1
     1     1     0     1     1     1
     1     1     0     1     1     1
     1     1     0     0     1     1
     1     1     0     0     1     1
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     0     0     0     0     0
     1     0     0     0     0     0
     1     0     0     0     0     0
     1     1     1     1     1     1
     1     1     0     1     1     1
     1     1     0     1     1     1
     1     1     0     1     1     1
     1     1     0     1     1     1
     1     1     0     0     1     1
     1     1     0     0     1     1
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     1     0     0     1     0
     1     0     0     0     0     0
     1     0     0     0     0     0
Remi-Gau commented 1 year ago

what I think I am going to do is to modify how the slice time correction is run: I will run one job per run if not all runs have the same slice timing, but it will defo throw a warning

Remi-Gau commented 1 year ago

that means that slice timing will be run on your data but you should probably figure out why your data has different slice timing for different runs

JacMatu commented 1 year ago

Thank you Remi, I'll try to get in touch with physicists from my previous lab on that. In the meantime, should I re-run the preprocessing for everyone with slice timings performed run-by-run?

My main folder goes through the BIDS validator without an error, sorry I just copied 2 subjects to the gin repo to share with you.

Remi-Gau commented 1 year ago

Thank you Remi, I'll try to get in touch with physicists from my previous lab on that. In the meantime, should I re-run the preprocessing for everyone with slice timings performed run-by-run?

I suspect you will have to re-run your preprocessing for everyone indeed.

Once again the differences are not big so I would be surprised if this made a difference in the end. But maybe just to make you can make sure that things were done right.

My main folder goes through the BIDS validator without an error, sorry I just copied 2 subjects to the gin repo to share with you.

ha OK I wondering how you were getting bidspm started otherwise. 😮

JacMatu commented 1 year ago

Ok, should be easier when it works for every subject instead of trying to find a pattern or errors like a madman.

Let me know if that's something that I should change in bidspm config locally or do you plan to have a dedicated branch with a different slice timing approach that you described.

Remi-Gau commented 1 year ago

most likely I will open a PR to make bidspm smarter and do this kind of thing automatically, so the only thing you should have to do is update bidspm and run it

Remi-Gau commented 2 months ago