BIDS validator errors and .json necessity

I would really appreciate someone’s help on this:
I have been struggling with making a BIDS compatible dataset without success:
I have 141 subjects and each subject has two consecutive runs of T1w (MPRAGE). Per BIDS tutorials on hierarchy, I can omit having a “session” folder altogether as each sub has only one session.

  1. It keeps giving me error regarding my naming scheme and that it has illegal characters. Each of my 141 subjects has two final files:
    can you spot what is wrong with the naming?

  2. I don’t have a json file for each nifti file. is is necessary? I plan to only include one json file in ./MyProject folder

  3. I also get the error: no valid data found for subject. I have .nii T1w files that have been defaced and I also have edited the header so that it doesn’t contain any identifying data. what could be wrong with it?

Thank you…

guess I found my answers. fingers crossed!

You may have resolved your issues, but just to quickly answer:

You have an extra suffix run0[12], which is invalid. There isn’t a run- entity for T1w images, but you could use acq-01 and acq-02 just to indicate that you ran it twice. If used different sequences, you might indicate them with something like acq-MPRAGE.

The simplest answer is that any mandatory metadata must be associated with each file, but this can often be done in the root via the Inheritance principle. Happy to elaborate if needed.

I suspect this is just #1 revisited.

So you mean _run is specifically used for fMRI data? I just switched the way I named in this way and it seems to be working-however I am not done with all:
sub-01_run-01_T1w.nii.gz instead of sub-01_T1w_run-01.nii.gz
it now recognizes the sequence as T1w
Do you still think that I should use _acq instead of _run? we ran 2 consecutive MPRAGE sequences with exact same parameters

Actually, I was wrong. It looks like run- is allowed. There’s an inconsistency in the entity table then, which is what I was going off of when I suggested acq.

got you. thanks a lot though.
I think I’ll send a note to BIDS as the specifications states _run should be a “suffix” which mislead me, but they have an example that uses it prior to Data type.

Hi Chris
Thought I’d resurrect this thread rather than start a new one. I am BIDSifying data from various public sources that do not have JSON sidecars for the raw data, but have a published description of the scans with some of the physics parameters. It seems like using inheritance here is the apt choice. I just want to confirm that it works as I expect.
Since inherited atlas labelling for a desg image is done using a file dseg.tsv in the pipeline root directory, I assume the same would be done for raw data. E.g. I would have two files, T1w.json and FLAIR.json in the rawdata directory giving the physics parameters for images with those suffixes.
Bonus points for a less frequently occurring case: if I have different acquisitions of the same scan type, can I inherit values from two files in dataset root, e.g. acq-2D_FLAIR.json and acq-3D_FLAIR.json?
Bonus bonus points for a theoretical case I haven’t seen. What if I want to inherit values based on more than one entity separated by an entity that is not used? Starting with the specified order of entities:
For example, I want to have sidecars inherited by scans based on ‘ses’ and ‘ce’ but not ‘acq’. This may never occur or may be better represented using ‘acq’ instead, but thought I’d put the question in for completeness as someone else might find the answer useful.

These should all absolutely work. I would always test with pybids to see whether they work in practice. Here’s a practical example for checking whether the metadata is findable (adapted from this presentation):

from bids import BIDSLayout
layout = BIDSLayout("/path/to/rawdata")
flair2d = layout.get(suffix="flair", acquisition="2D", extension=".nii.gz")

If it’s not, it might be a pybids bug, so in that case, check the validator to make sure things are okay and then open an issue.

So I’m interpreting the question as, can I have several things like:


In this case, FLAIR images that have acq-2D would inherit metadata from the first, and FLAIR images that have ses-1 AND ce-gad would inherit metadata from the second. If an image has all three, it’s actually ambiguous, and so the standard says (my emphasis):

no more than one applicable file may be defined at a given level

Hopefully that answers your question?