That’s at the bottom of the output I posted above:
!tree {rpt.root}
Is the output above listing all the files in the BIDS project, or just the outputs from the reportlet? If the former, then unless I’m misunderstanding the output, this looks to me like a potential problem with the file naming, not with PyBIDS. If the listing above is accurate, only some of the files have run included, and they’re all in ses-03. It’s not clear how PyBIDS is supposed to infer the run name automatically, given that you can have multiple runs per session (or not).
If this is just showing the files that have report output, could you produce a listing for all the files, including ones that aren’t showing up? If the issue is the same as above (i.e., no explicit run in the file name), then the obvious fix is to add explicit run key-pair values to all filenames, as there’s no safe way to automatically infer them.
Look back over what has worked and what hasn’t, it seems that my file naming may in fact be to blame. I only included a run tag in instance where there were more than one run of a particular task. Most of the time that didn’t happen, but some subjects had multiple runs in a single session. It seems like it has worked fine in cases where nothing has a run label, but if any scan has a run label, then only scans with run labels are included in the report.
Comparing side-by-side our config vs. current default config there seems to be differences for some keys, e.g.:
{
"name": "subject",
"pattern": "[/\\\\]sub-([a-zA-Z0-9]+)",
"directory": "{{root}}{subject}"
},
and “official” config:
{
"name": "subject",
"pattern": "[/\\\\]+sub-([a-zA-Z0-9]+)",
"directory": "{subject}"
},
we are using PyBIDS 0.9.2 - @tal should we get that config [fmriprep’s] updated ASAP?
I think the lack of explicit run labeling is the issue here. It may not be required by the spec, but in practice, if you have more than one run across your project, I think it’s pretty much mandatory for disambiguation. I’d maybe consider making that explicit in the spec if it isn’t already there.
If you update the filenames to include run and still have problems, feel free to open an issue on the repo!
@oesteban yes, that would probably be a good idea. I suspect this might prevent you from using .get(return_type='dir') properly (though everything else should work fine).
1 Like
Alright, I think I’ve figured out why I was still getting complete reports in cases where there were no run labels at all. Pybids still doesn’t find any runs in that case, as @tal described
These lines in reports.core pull combinations of all the levels of sessions, tasks, and runs. In the case where there are no runs, then it’s just all combinations of sessions and tasks, so all of the reportlets get returned and are added to the final report. If there is a single run that has a run key and value, then all of the combinations produced have that run value as part of the query, so only the runs with a run key and value get included in the report. The solution then, as Tal said, is to put a run number on everything.
Thanks for your help resolving this everyone.
1 Like
I’ll have a look into whether we should require that explicit run labeling.