Skip to content
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

ENH: Add writer for Siemens CSA header #417

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

moloney
Copy link
Contributor

@moloney moloney commented Mar 3, 2016

Allows us to take a parsed CSA header and convert it back into a
string. Useful for things like DICOM anonymization, or perhaps
round tripping DICOM -> Nifti -> DICOM.

@moloney
Copy link
Contributor Author

moloney commented Mar 3, 2016

This is another bite-sized chunk from #290.

I was tempted to make a csa module with the read/writer functionality and then setup some proxies in csareader for backwards compatibility, but I am not sure it is worth the hassle?

It would also be nice to use ElemDict objects (as specified in #416) for the parsed representation. Again, I guess we need to provide some backwards compatibility here.

@nibotmi
Copy link
Contributor

nibotmi commented Mar 6, 2016

☔ The latest upstream changes (presumably #393) made this pull request unmergeable. Please resolve the merge conflicts.

@matthew-brett
Copy link
Member

The csa representation as we wrote it originally is a bit kludgy, I think - if you're interested - it would be worth improving that with a new csa module, and depracting the csareaders module.

I don't think we have to worry as much as usual about backwards compatibility - the nicom module has always had a bit fat warning on it. So, avoid breakage if possible, but don't do excessive work to keep compatibility otherwise.

@matthew-brett
Copy link
Member

By the way - thanks very much for breaking out the change from the big PR - it's extremely helpful.

Allows us to take a parsed CSA header and convert it back into a
string. Useful for things like DICOM anonymization, or perhaps
round tripping DICOM -> Nifti -> DICOM.
@codecov
Copy link

codecov bot commented Mar 24, 2020

Codecov Report

Merging #417 into master will decrease coverage by 0.03%.
The diff coverage is 81.63%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #417      +/-   ##
==========================================
- Coverage   91.70%   91.66%   -0.04%     
==========================================
  Files          96       96              
  Lines       12311    12360      +49     
  Branches     2173     2186      +13     
==========================================
+ Hits        11290    11330      +40     
- Misses        684      690       +6     
- Partials      337      340       +3     
Impacted Files Coverage Δ
nibabel/nicom/csareader.py 85.86% <81.63%> (-1.54%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 65d5fc6...122a923. Read the comment docs.

@moloney
Copy link
Contributor Author

moloney commented Aug 9, 2021

@ZviBaratz @matthew-brett @effigies

During our recent meeting, I forgot the original reason I wrote this was to support anonymization of Siemens mosaic/DWI Dicom files (not round-tripping back to DICOM). The standard way to anonymize DICOM removes all private headers, but then you lose the mosaic info and b-values/b-vecs. You can whitelist the CSA sub-header with this info, but at least some versions of the scanner software will use uninitialized memory for the CSA buffer and then leak PHI in the unused portions. So by parsing it and rewriting it with this code (which does zero out the memory) you can avoid this issue. So... it is pretty niche but still useful.

This also got me thinking, is dicom_parser going to make any attempt at supporting anonymization? Should we start a dicom_anon project?

@ZviBaratz
Copy link
Contributor

I haven't really given it much thought so far, but I definitely support the idea. Do you think a separate package will be better? I feel like it could probably be added to dicom_parser fairly easily, but it's possible I'm simply not aware of some anonymization edge-cases, such as the CSA thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants