-
Notifications
You must be signed in to change notification settings - Fork 8
dicom2spec error due to checking for spec key "id" which does not exist #173
Comments
Hmm. Two things: First of all, the immediate issue seems to be that the spec that is being worked over here has no Secondly, what this is trying to achieve is a guess as to what run to use when there appear to be several. If we have several series with the same description and the same previously determined run number, then this tries to check those |
Re no In my case tarballs, the different runs are explicitly noted in the |
Note that since there is not datalad-hirni/datalad_hirni/commands/dicom2spec.py Lines 433 to 435 in c87946d
|
Well, as far as identifying an entry in a spec goes, that's an option. But implies no order in time, so not useful for what that piece of code is trying to achieve.
Can I see them?
Okay, need to have a closer look how that can be. Having your custom rules might help, though. |
cannot attach a .py file.. so here it goes:
|
Thanks! Will look into that more closely. |
No, this piece of code is executed after the rules (which it probably shouldn't, but that's another issue). If your rules really weren't triggered, they are prob. not correctly configured. The dataset should have a config (or several in correct order)
This sorting "works" because it assigns a sorting key of |
Hah, hold on. Looking for another reason why your rules might not have been executed, I noticed hirni didn't catch up on a change in datalad core. With a current datalad installed, it would indeed fail to get your rule, if there are multiple rules configured. Is that the case, @pvavra? Note to myself: |
Assuming that your rules weren't picked up, in my estimation it's simply the only one where default rules would derive the same run from the protocol field for several series. Could that be true? |
A change in behavior of datalad's ConfigManager.get method, requires the use of get_all parameter in order to get all configured values. Adaption to that change missed this usage in dicom2spec as discovered in issue psychoinformatics-degh-173.
Don't apply an id based decision regarding duplicate runs if there's no id to be found in the spec snippets. See psychoinformatics-degh-173
No, nothing really relies on it so you don't break anything. If you end up with a specification containing duplicates, however, conversion based on it might go wrong. In any case, if you could retry with the branch of PR #174 to confirm this issue doesn't get triggered, that would be great. |
A change in behavior of datalad's ConfigManager.get method, requires the use of get_all parameter in order to get all configured values. Adaption to that change missed this usage in dicom2spec as discovered in issue psychoinformatics-degh-173.
Don't apply an id based decision regarding duplicate runs if there's no id to be found in the spec snippets. See psychoinformatics-degh-173
@pvavra, can you confirm PR #174 works for you? Regarding this:
I'll take that back. I think there should be a serious refactoring instead, that would turn that part into a rule that is used by default (and can be used in a custom setup, too, if so desired). |
I'll give the PR a try, but am not sure what the simplest way for me to test it is... Create a dedicated |
@pvavra Sorry for answering a little late - just back from vacation. I'd go for a dedicated venv, yes. You can then install the PR (or any particular branch/tag) like this: |
If you want to work on PRs yourself anyway, there's another approach that I usually use, @pvavra. |
when importing a tarball (can share on medusa if desired), I am getting the following error:
[ERROR ] 'id' [spec_helpers.py:get_specval:33] (KeyError)
it seems to stem from the implicit call on line:
datalad-hirni/datalad_hirni/commands/dicom2spec.py
Line 451 in c87946d
Indeed, for all the other tarballs this error did not get triggered. I assume that some of the preceding conditions of the if clause were False for those other tarballs (tested only with one other atm) and hence that line did not get executed.
However, I do not understand what that conditional is trying to achieve. Why should any of those conditions lead to the series being ignored for the conversion in the first place?
The offending dicom series in this particular case is a SBRef image related to a functional run and should be converted.
Or is it related the sorting needing RF a few lines above?
As a quick workaround for this particular dataset, I can simpy comment out the whole for loop starting on line 436:
datalad-hirni/datalad_hirni/commands/dicom2spec.py
Lines 436 to 456 in c87946d
But not sure I am not breaking anything further down the line by it..
The text was updated successfully, but these errors were encountered: