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

What does NORM in 0008,0008 (image_type in our dicominfo column) actually means? #266

Closed
yarikoptic opened this issue Oct 23, 2018 · 5 comments

Comments

@yarikoptic
Copy link
Member

Dealing with scanner for a T1 or T2 anatomical producing two series (dicom folders) which seems to differ (have access only to our dicominfo.tsv, may be there is more) only by the 2nd one having also NORM in the image_type. So in total it has ('ORIGINAL', 'PRIMARY', 'M', 'ND', 'NORM').
I only wonder why it is not "DERIVED" (instead of "ORIGINAL") if that "NORM" means "normalized" (either spatially or numerically). Couldn't find a clear answer to the meaning of NORM in a quick google search.

@darcymason , @moloney - if you have some info to educate me, would be appreciated. My dicom foo is quite basic.

@neurolabusc
Copy link

neurolabusc commented Oct 24, 2018

Norm refers to a Normalized Pixel. On the Siemens console the user can select if they want to adjust for field homogeneity differences. If this is turned off, the raw data will be stored and you may see regional differences in tissue intensity (e.g. deep white matter appears darker than superficial white matter). In the corrected image the white matter intensity will appear more consistent. Most neuroimaging pipelines include sophisticated offline bias correction (e.g. N4 or SPM's bias correction built in to the unified segmentation-normalization). Therefore, my assumption has been that the online correction probably has little impact one way or the other.

Like you, I am often surprised how rarely the vendors use the DERIVED tag. Here I think the ORIGINAL tag is preserved because their is a one-to-one correspondence with raw data (in contrast a TRACE image is only derived from a series of raw DWI scans, and so is not original).

@neurolabusc
Copy link

As an update, please note the distinction between ND, NORM, DIS2D , DIS3D. Also note that Siemens is moving non-standard attributes from the public ImageType tag (0008,0008) to the private ImageTypeText (0021,1175) tag. see dcm2niix issue 597 for details.

@raamana
Copy link

raamana commented Jul 12, 2023

Hi Chris, I notice your comment that saying you are often surprised how rarely the vendors use the DERIVED tag. can you elaborate further? we notice it was used by Siemens for EPI motion correction and ASL processing in one of our projects (see here), but I am wondering if we can generally depend on it across vendors? it appears you don't think so, but this DICOM tag would be an ideal way to do it for us as we plan to depend on DICOM headers alone if possible.

We are looking for a generally robust way to distinguish RAW vs Derived so we can skip protocol compliance checks on derived DICOMs in mrQA and limit our reports to original acquisitions only

@neurolabusc
Copy link

For any reconstructed magnitude image, the term DERIVED is in the eye of the beholder (e.g. they are all derived with a FFT). There is a judgement call of whether homogeneity correction, combining data from multiple coils, level of deep learning artifact removal, etc. are original or derived.

In general, when many raw pixels are used to derive a single pixel, the derived value is applied. For example, with DWI I would expect TRACE, ADC, etc to be derived.

However, situations like homogeneity normalization or MOCO motion correction, the definition seems ambiguous.

@raamana
Copy link

raamana commented Jul 13, 2023

yeah, true.

atleast for our purposes in mrQA, what we wanted to robustly identify is additional and derived scans (such as MoCo EPI) on top of regular scans (usually raw/unprocessed EPI, but could have basic preprocessing* applied within the scanner itself). if there is only one volume for a given sequence in the protocol, we'd use it to check for protocol compliance. if there is more than one, we'd have to find a way to pick the one closest to raw acquisition (one less processing step applied).

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

No branches or pull requests

3 participants