-
Notifications
You must be signed in to change notification settings - Fork 262
DOC: Dicom doc. improvement #910
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
Merged
Merged
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
299bbcf
Update spm_dicom.rst
jond01 f0c0cd8
DOC: dicom orientation (-1 + N) -> (N - 1)
jond01 0f86986
MNT: Added .idea/ to .gitignore (PyCharm)
jond01 70b0697
DOC: Added explanation for Spacing Between Slices
jond01 5dcdccd
DOC: Moved Spacing Between Slices to a note
jond01 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -17,6 +17,7 @@ | |
.pydevproject | ||
*.py.orig | ||
.DS_Store | ||
.idea/ | ||
|
||
# Not sure what the next one is for | ||
*.kpf | ||
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh dear - I see now that it is more complicated than I thought when I wrote the original - https://stackoverflow.com/questions/14930222/how-to-calculate-space-between-dicom-slices-for-mpr - what do you think we should do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the method with Image Position (Patient) is more general, as some dicoms may miss the Spacing Between Slices attribute.
If both attributes appear, then filling the third column in the affine is possible with either:
And they are equivalent (at least are expected to be).
Method 1 is described thoroughly in the doc:
https://nipy.org/nibabel/dicom/dicom_orientation.html#d-affine-formulae
Method 2 may be helpful in some special case: you have just one slice (N=1) but still want the third column of the 4x4 affine matrix. It can be achieved with:
In summary, it does not contradict anything but worth mentioning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - I think the question is whether to add the explicit mention of the DICOM Spacing Between Slices attribute here - because it looks like it is a pretty unreliable method of getting the thing we want, which is the distance between the center of one slice and the center of the next: https://groups.google.com/forum/#!msg/comp.protocols.dicom/gyvsgAj4y6o/KOjJywTWFlAJ
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the bold part here can be moved to some footnote:
However, from my experience when this tag is there - it is correct, i.e. it agrees with the current method.
David A. Clunie is a reliable source, but it was 20 years ago. I think that today most of the manufacturers comply with the definition in the standard, which is exactly what we want:
From:
http://dicom.nema.org/MEDICAL/dicom/2015b/output/chtml/part03/sect_C.7.6.16.2.html#table_C.7.6.16-2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's reasonable - maybe with some discussion like here so people know to be a little careful.