-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fieldmaps acquired during each part of a session splits into two not differentiated #624
Comments
d'oh, not nice indeed. Moreover I am surprised that you get files from multiple studies get into a single .nii.gz! smells like something to clear up with sidenote:
yes, there is also |
dcm2niix is working as intended. It seems like heudiconv needs to resolve the correct IntendedFor when using the |
Yes indeed Accession id is the same for all sequences across the two study UIDs in my case, but in our case we do want both field maps in the same session, just not considered as a single fieldmap. There are different approaches to this, one would be to enrich the dicominfo file with fields allowing to differentiate the fieldmaps. Then |
sorry for the noise -- I have misread ". The resulting detected fieldmap magnitude ('M' in protocol type) has then twice the number of files" as ending with "number of volumes", my bad. I am still not clear though on how |
@yarikoptic just to be clear, both magnitude and phasediff are combining files from two different sequences (happening in two different sessions study UIDs), so both of them show in dicominfo as sequences with twice the number of files. But at time of conversion you are right they are separate volumes although with 4 magnitudes and 2 phases instead of two separate sequences with 2 magnitudes and 1 phase. So in dicominfo one would expect 4 rows, two with If the study UID was taken into account to detect individual sequences in dicominfo and related, then I believe this would resolve the problem. And it would make sense as a single sequence is never spread over two sessions (hate to say never but that's maybe one rare case it could be said i believe). |
@yarikoptic yes indeed that the PR i saw some time ago which would probably help with this kind of issue ! |
@yarikoptic Now that i had time to go back to that issue, I found out this is because series are identified only from their instance number and protocol name. So if two different studies acquired in the morning and afternoon are merged ( More precisely, this is because the series identification is not done with the DICOM field Lines 159 to 168 in f4e4896
First question is: why the DICOM Series UID was not used for that ? Couldn't we just replace this custom SeriesID object with simply the value of In any case meanwhile I made PR #684 to minimally change the code to include the series UID in the grouping key. This way two series with same instance number and protocol name belonging to two different studies UID are correctly disentangled. Lines 160 to 171 in c6c7106
Note: to still make the series id string representation readable, i computed a hash truncated to the first 16 characters, but the full series UID could be used instead (may be less readable though) |
@yarikoptic i just saw you merged the other PR, great ! Did you also see #684 ? I am tagging you again as this issue is old so not sure you got the notification. |
I saw it but yet to provide feedback |
It is relatively common to have a single theoretical session splits practically into two sessions due to the length of the protocol, so e.g.
anat
,task 1
,task 2
,fmap
in the morning andDWI
,task 3
,fmap
in the afternoon.heudiconv can deal with this with the option
-g all
to group all files no matter the series UID which changes after each practical session and would give an error otherwise.The issue I am having is that when the grouping is applied to a dataset with a fieldmap having the same series id (e.g.
2_myfieldmap
) during each practical session, the two fieldmaps are not differentiated as can be seen indicominfo.tsv
. The resulting detected fieldmap magnitude ('M' in protocol type) has then twice the number of files, and same for the phase, resulting in this kind of output for conversion:Would there be any suggestion on how to tackle this issue ?
Would the only solution be to convert each practical session (i.e. with a unique study UID) separately and group them later in a single theoretical session ? This would be quite cumbersome and a shame considering the great
-g
option normally made for this kind of case.The text was updated successfully, but these errors were encountered: