Combined DWI scheme with different acquisition parameters

[kabilar]

Hi BIDS team, we have a situation that is different than the Multipart (split) DWI scheme, whereby we have acquired a single concatenated DWI run but parts of the DWI run have different acquisition parameters (i.e. echo time [TE], time between the leading edges of two successive diffusion-encoding gradient pulses [Δ], duration of a diffusion-encoding gradient pulse [δ]). It is ideal for us to keep this data as a single volume since downstream analysis is performed on the entire DWI run.

Right now we are thinking of saving sidecar files similar to the .bvals and .bvecs with the TE, Δ, and δ as .techo, .tbigdelta, .tsmalldelta, respectively. What do you think? Happy to submit a pull request to the spec if this approach is agreed upon. Thanks.

cc @satra @Tinggong @ayendiki

[kabilar]

One alternative option would be to break the DWI run into separate volumes using the acq-<label> entity and create a sidecar json file for each volume with the different parameters.

[kabilar]

I just noticed that the EchoTime can be an array of numbers. Another option is that once #2309 is approved and merged, then we could define the DiffGradientDuration and DiffGradientSeparation also as an array of numbers.

[kabilar]

I have updated my above comments to reflect some discussions I have had with @ayendiki and @Tinggong via email. And submitted #2320 for review. Thanks.

[tsalo]

Right now we are thinking of saving sidecar files similar to the .bvals and .bvecs with the TE, Δ, and δ as .techo, .tbigdelta, .tsmalldelta, respectively. What do you think? Happy to submit a pull request to the spec if this approach is agreed upon. Thanks.

Given that other modalities (esp. ASL) encode similar metadata as array-type fields in the sidecar JSON, I'd do that, as with EchoTime.

[kabilar]

Given that other modalities (esp. ASL) encode similar metadata as array-type fields in the sidecar JSON, I'd do that, as with EchoTime.

Thanks @tsalo. I was leaning to this option as well but then realized that our acquisitions could have hundreds to thousands of values for the echo time, diffusion gradient duration, diffusion gradient separation fields. This might make the sidecar JSON file difficult to navigate. What do you think?

[tsalo]

I agree that there are denser, more readable organizations for volume-wise metadata data, such as tabular files with rows for volumes and columns for metadata fields (much like aslcontext.tsv files), but I think that will have to be pushed until BIDS 2.0 (assuming other people feel similarly). I think adding support for volume-wise metadata fields in the JSON is the most BIDS-y way to accomplish what you need, even though the JSONs will be less readable.

[kabilar]

Thanks @tsalo. That sounds good. I will update my pull requests.

[ayendiki]

Is there a plan to handle bvals and bvecs this way as well?

…

________________________________ From: Taylor Salo ***@***.***> Sent: Thursday, January 22, 2026 4:56 PM To: bids-standard/bids-specification ***@***.***> Cc: Anastasia Yendiki ***@***.***>; Mention ***@***.***> Subject: Re: [bids-standard/bids-specification] Combined DWI scheme with different acquisition parameters (Issue #2302) External Email - Use Caution [https://secure-web.cisco.com/1vqG18SNwQkJJ5T9O8121iFpLgmpgHgvefDIPAXQdUNOprT79OYnDYWChVwhekkS_hXU19eC-kpnSrvYHQYUmp0-khHcTUttw7viJKXTSOHblbkrEY4eVzI01650TqjhG1NxgI5SM5fvElSVuZ-yUSy-wYbUv4Hs_4w0X_R6HzaIKwiykEG-npnamNcXWHQ4Jng3eKrqi1mtJHsbBlNFh-e9X5mx7JEDQYEE3JrbOE5N5EiDphr2tLSGNApA5z005IE9R5lYZ5E65sM-JyTeYhffgfsPqf4lVPQ4DNipmZ1UF80uH3D3WSvsNSwy-Io99/https%3A%2F%2Favatars.githubusercontent.com%2Fu%2F8228902%3Fs%3D20%26v%3D4]tsalo left a comment (bids-standard/bids-specification#2302)<https://secure-web.cisco.com/1pszb_sw-qBvqo0sGt580HfW1Bw-rFv3bgjKHOEAQ-a6CVfe0qrMK6VFX4OgZ-q3ufd2pJfELQppZEoAYjzAJl7d7uMBQJxWPGSpz-3A1skkz3wQUZgdPtn0-3JlPmOXq0yY1Fkq4004IfhO6cb-XOLL-debexjw4QVF-4Cb-fS6kVC8m1rimyVH9XQo2H-9MQdzlo4iWRbOamHaNF2kjznpbg55cc1KOIbhBslVnwslt-C9rmDckxlJ9OtciU933ZXrGPsrx_-QCiceTQmEbnvyW4RObZkODWIsEwlp4lrm1dMaanayHa3qN8xQFYdMm/https%3A%2F%2Fgithub.com%2Fbids-standard%2Fbids-specification%2Fissues%2F2302%23issuecomment-3786957403> I agree that there are denser, more readable organizations for volume-wise metadata data, such as tabular files with rows for volumes and columns for metadata fields (much like aslcontext.tsv files), but I think that will have to be pushed until BIDS 2.0 (assuming other people feel similarly). I think adding support for volume-wise metadata fields in the JSON is the most BIDS-y way to accomplish what you need, even though the JSONs will be less readable. — Reply to this email directly, view it on GitHub<https://secure-web.cisco.com/1pszb_sw-qBvqo0sGt580HfW1Bw-rFv3bgjKHOEAQ-a6CVfe0qrMK6VFX4OgZ-q3ufd2pJfELQppZEoAYjzAJl7d7uMBQJxWPGSpz-3A1skkz3wQUZgdPtn0-3JlPmOXq0yY1Fkq4004IfhO6cb-XOLL-debexjw4QVF-4Cb-fS6kVC8m1rimyVH9XQo2H-9MQdzlo4iWRbOamHaNF2kjznpbg55cc1KOIbhBslVnwslt-C9rmDckxlJ9OtciU933ZXrGPsrx_-QCiceTQmEbnvyW4RObZkODWIsEwlp4lrm1dMaanayHa3qN8xQFYdMm/https%3A%2F%2Fgithub.com%2Fbids-standard%2Fbids-specification%2Fissues%2F2302%23issuecomment-3786957403>, or unsubscribe<https://secure-web.cisco.com/1UAdhPFlI_z-Zh2JWkqAltGFPH1VL24RvRsCG_49Ps21TbdSL7l1T6T8ZErBwITd7uZTCYsGU8CyJQuFe0-2JLqutZlX0xCw9VrAsWkIzujAfGYhNtG-l4TntYTCa72UIleJiFhAfVhc1d2ygXYDDsmCtnF9_ai0MNzVyuSy0lfvmuz9bgEsPj0Yg0nyWZnyA9Fpmj5okv-RLcDoULltR2N1KqylEaS4KyAxv7ssTmCpfQTb-jj4PISqSWRtdDDlApPjNMQ5-XtMSomXuva8uuEoQ4B7Uc03LGlgQ-VYOlSzQkN4_CBLIgWTiFzS1XusV/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADU34V6HY6EDSNBABK4FTYT4IFBSXAVCNFSM6AAAAACRLR6JIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOBWHE2TONBQGM>. You are receiving this because you were mentioned.Message ID: ***@***.***> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline <https://www.massgeneralbrigham.org/complianceline> . Please note that this e-mail is not secure (encrypted). If you do not wish to continue communication over unencrypted e-mail, please notify the sender of this message immediately. Continuing to send or respond to e-mail after receiving this message means you understand and accept this risk and wish to continue to communicate over unencrypted e-mail.

[effigies]

Is there a plan to handle bvals and bvecs this way as well?

I haven't seen anybody put forward a plan thus far.

[tsalo]

@mattcieslak has a pretty old PR (#352) that I believe would have put bvals and bvecs into a single tabular file, but I don't think anyone has proposed putting them in the JSONs.

[ayendiki]

It seems to me like these should all be treated consistently: bvec, bval, TE, δ, Δ, per DWI volume. They are the dimensions of multidimensional dMRI sampling. If the BIDS team has a preference, let's adopt it for all of them, otherwise let's go with separate files which is how bvecs and bvals are currently handled.

…

________________________________ From: Taylor Salo ***@***.***> Sent: Friday, January 23, 2026 11:13 AM To: bids-standard/bids-specification ***@***.***> Cc: Anastasia Yendiki ***@***.***>; Mention ***@***.***> Subject: Re: [bids-standard/bids-specification] Combined DWI scheme with different acquisition parameters (Issue #2302) External Email - Use Caution [https://secure-web.cisco.com/1GGYYbfcvwlpefywKOi6aiNoFn0-f-OiYsOqy2Py5RPQLSV8KbcaBoiNMOMduxjoqnBiPM8R47IEyj4-Abbnd90vDURguEjc6SQI85oLUfsXe4OYPPN6jooVqQR6alJMph0_bW8qZxZkrr8zt7eQw_rLQLf4Mkiyz-6l3u-FYCDWE4Av9yq21x-A7uLOoBvq7CTFdG6bryR2T0Ypc0tAn5FEX3S-OjdwW_TqRMc4iWXMcE08GR-VOFLBVdGFB30YzbpQbi2m53cBCjPnbQVlb7F9YNGQmk7OuZixiRKDysiO9LgBFqZ4ze93KJ1TrKHOV/https%3A%2F%2Favatars.githubusercontent.com%2Fu%2F8228902%3Fs%3D20%26v%3D4]tsalo left a comment (bids-standard/bids-specification#2302)<https://secure-web.cisco.com/1HUWJvPrOzia0IJFEtoKxZFt_oh0e_pWU-rT6yWLT2SMG6d7An5bujYb1aDbJzZRnmoMJwwA9w3l8k2IEB2U9jB1P_9HAjPWPzLmIqFHKdRzXkGdSl4jfensjTj7M30-bM96k3905Zb5qNmvIqbvQcnh1ObLr9Nv38ka7iYfqFy6pzBV6oahifa-5xytfYPkEIU3pVK7XwQI8D5eTf2sWVHjd1BSmhXJB61qIs21Jelc-9eouTKOUJdSXmNB2PSBMk9BZdyzVodX2Wv8XQBxSSVrWgFbvA--_vERT50f9yEyj1c4_nFEn8f0jEFcGkp8F/https%3A%2F%2Fgithub.com%2Fbids-standard%2Fbids-specification%2Fissues%2F2302%23issuecomment-3791022299> @mattcieslak<https://secure-web.cisco.com/16w5zLOzhAnWD2K4xj1BViCuic0S-F6-ac4COeqikLdxkw0er3LOfrHrO0ia0g_AO_Sz9n8JIfQ3GeeKL23kP58hwqko9cOVK4HhF9etbnMc2Qu4ugUOXdPw7wTza5QHV8ZkfFmtS9CuUcVVbFQAjm19U8o6zYMzGAQsDK44WdRQ_AIHF6Z7fkXykgMa-wCAIY9MYchkdijk1GcPMhcquosCM0SEm8L_USFnKtyR6zQpGi2boaxwYepaui9r8X8g4VqoAnJtOjjkR2ePRMiPej7jGemJ_j5TFshoxXg2misFRm1Tlzo5VIjf-S6tiHQIv/https%3A%2F%2Fgithub.com%2Fmattcieslak> has a pretty old PR (#352<https://secure-web.cisco.com/1L4l2_wPhPLB5IUZmBHvv9oiBXvcm2Ng89A2vAdwWUMGM3pdR_ZYVA_Kl3gAPJQVe-gF9ynsM_4Ef4tebMX3yWP7i-O1lLBcIiWBCV0nQRn8qReWgV2Sypi5jrtv62vwUsjijBfq3XGGl13TcFYW6ZOC67a8OFaKDWrK7Nl6VDVn-7coaQj8kR1vK6JmybDShmVzXdG9wJBB5bROt1My72jLKBuIQNftZbtoshXFscISwtuwv3YKdIpXaXf6ZIZMZi6-bMnlCVutppp0pSBT5fkBCE6YxUKVY-x3lDqzOy5035ylfkA5RJ7qjM77mbyEK/https%3A%2F%2Fgithub.com%2Fbids-standard%2Fbids-specification%2Fpull%2F352>) that I believe would have put bvals and bvecs into a single tabular file, but I don't think anyone has proposed putting them in the JSONs. — Reply to this email directly, view it on GitHub<https://secure-web.cisco.com/1HUWJvPrOzia0IJFEtoKxZFt_oh0e_pWU-rT6yWLT2SMG6d7An5bujYb1aDbJzZRnmoMJwwA9w3l8k2IEB2U9jB1P_9HAjPWPzLmIqFHKdRzXkGdSl4jfensjTj7M30-bM96k3905Zb5qNmvIqbvQcnh1ObLr9Nv38ka7iYfqFy6pzBV6oahifa-5xytfYPkEIU3pVK7XwQI8D5eTf2sWVHjd1BSmhXJB61qIs21Jelc-9eouTKOUJdSXmNB2PSBMk9BZdyzVodX2Wv8XQBxSSVrWgFbvA--_vERT50f9yEyj1c4_nFEn8f0jEFcGkp8F/https%3A%2F%2Fgithub.com%2Fbids-standard%2Fbids-specification%2Fissues%2F2302%23issuecomment-3791022299>, or unsubscribe<https://secure-web.cisco.com/1gR5Zettu0NZ6rSh-QxasLuIxE2OcM9tRPzuNqTZXzOnAztHZcX64ZHGOoOWIdL8mqHklj1F2WTmAtDd64CKStCeP5F0jSYj8iUctFTlVCJcDsnLzDeOh7YbCb3WmiLjNe7DkaITfVyPTTYfz1mwnLvA1zCJqkbWCzlg4MAC-SSSHR2vZ5cyCbti3d6HRpQnNZsmUcpranLf-7mj1HL0nx1JlD6KQfat5hwQwCh-sO1utJe_7O0tzLLwSYflZIcQel82IKFuUv67z1ZcFRJXBuZdxAl6I3Ge6ix83KO2BnBUilVhpzbc-50eKMJCj10PL/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADU34V6YDXYZG667OQSALWL4IJCEJAVCNFSM6AAAAACRLR6JIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOJRGAZDEMRZHE>. You are receiving this because you were mentioned.Message ID: ***@***.***> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline <https://www.massgeneralbrigham.org/complianceline> . Please note that this e-mail is not secure (encrypted). If you do not wish to continue communication over unencrypted e-mail, please notify the sender of this message immediately. Continuing to send or respond to e-mail after receiving this message means you understand and accept this risk and wish to continue to communicate over unencrypted e-mail.

[effigies]

Are we getting into BEP33 space? https://bids.neuroimaging.io/extensions/beps/bep_033.html