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

[yarikoptic]

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]

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]

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]

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]

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]

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).