Open manuelakuhn opened 3 years ago
Two things in here, from my point of view:
To put that one step further, there could already be an error when the rule is applied, meaning dicom2spec or hirni-import-dcm are executed. This would make rule development much easier and user friendly.
I think the solution to that is a specification "validator" of some kind. A dedicated command, that can be called independently by users but also internally by spec2bids (and may be import-dcm).
Edit: However, such a command can't really cover the BIDS validity of the outcome of a specification before actually executing. Since arbitrary conversion procedures can be included, we can't predict outcome beforehand in a meaningful way. And after execution - well, there already is a BIDS validator. It can cover a few aspects of how a specification may be (technically) invalid, but less so its result.
I think the solution to that is a specification "validator" of some kind. A dedicated command, that can be called independently by users but also internally by spec2bids (and may be import-dcm).
Exactly what I was thinking :-) I think it is enough to check that hirni works fine with this rule and does not run into errors (e.g. because of a missing key as shown above). If the result after the conversion is bids conform or not that's what the bids-validator is for and I don't know if it is really necessary to have that kind of check, also partially, inside of hirni (overkill?).
Even though with the checks implemented, errors in the rule file will be unlikely, I still think that spec2bids
should not silently stop if anything goes wrong with the conversion.
As a side remark: Even though I know that #193 and #194 are connected to this (and I discovered them actually while working on this problem here), I thought that it would make your life easier to have them in separate issues (for me they reflected different types of problems)
I think it is enough to check that hirni works fine with this rule and does not run into errors (e.g. because of a missing key as shown above).
That's where things become a little complicated, though. hirni didn't run into an error. The conversion procedure just didn't produce an output. That procedure happens to be the default, but technically isn't part of hirni but the toolbox. You could use hirni without the toolbox and/or a different conversion procedure for the DICOMs (that may not be based on heudiconv). A specification validator could of course incorporate some knowledge of that default procedure and what it needs, but this needs to be done with awareness that such checks are only valid if the default conversion is actually used.
As a side remark: Even though I know that #193 and #194 are connected to this (and I discovered them actually while working on this problem here), I thought that it would make your life easier to have them in separate issues (for me they reflected different types of problems)
Yes, appreciated! :)
When adding the rule template in sourcedata, the conversion runs through without error, but no conversion data is available afterwards. This is triggered to the missing
bids-modality
entry in the rule template.-> runs through without errors or warnings [1]
-> no errors only some warnings about
WARNING: Missing specification value for key 'bids-modality'
(full output [2]) but result dir not generated:Adding
'bids-modality': None
to rule return dict in/tmp/datalad-tests/bids/sourcedata
does not change the outcome.Only after adding one modality for one type of data it works:
modify rule in
/tmp/datalad-tests/bids/sourcedata
-> result was generated without warnings:
1 directory, 2 files
[2]: