NonlinearGradientCorrection in json files from anat

[CPernet]

type: Feature request

background: scanners are able to generate distortion corrected anatomical images to account for the small gradient non-linearities.

BIDS-json info: whether the image is corrected or not can be encoded with the key NonlinearGradientCorrection set to True or False. It would be great if always set in the json file (even though it is optional in BIDS).

Known encoding from Siemens: ImageType tag gives away what we want (0008,0008) ORIGINAL\PRIMARY\M\ND\NORM vs. ORIGINAL\PRIMARY\M\NORM\DIS2D or ORIGINAL\PRIMARY\M\NORM\DIS3D and also the private tag (0051,1016) M/ND/NORM vs p2 M/NORM/DIS2D or M/NORM/DIS3D

[neurolabusc]

@effigies do you have any opinion on this? dcm2niix does store DICOM tag 0008,0008 as the field ImageType in the JSON file, so my sense is this is redundant.

[CPernet]

you are right that is is there - just asking to make it bids :-)

[effigies]

@neurolabusc At least MRI+PET datasets need this tag defined in their MRI images, so one way or another users are going to need to convert from DICOM tags (or ImageType) to a boolean. Up to you whether this goes in dcm2niix or is a post-processing step for dcm2niix wrappers.

[CPernet]

FYI the reason it came about is that while my wrapper was updating the json for ND (ie corrected) data, I realize that the original needed updated too (because if PET is present that optional field is mandatory not matter corrected or not) -- so if that was added by default then there would be no more issues

[neurolabusc]

@effigies I would prefer if you decide whether it belongs in dcm2niix or not. I guess my concern is that while it is a convention for Siemens to use NORM for this feature, it is not defined in the DICOM standard and therefore I am not 100% convinced it is always populated correctly and that this term might be used for different types of normalization. If this is the only way that Siemens uses the term NORM, I am happy to set NonlinearGradientCorrection to true, but if it is not present I would be wary of setting NonlinearGradientCorrection to false. In particular, I suspect 0008,0008 gets modified by some PACS systems, in particular those that adjust the image in some way (e.g. set the DERIVED flag). My primary concern is that if dcm2niix sets this flag, it suggests a strong level of confidence in its usage.

[mharms]

Just a correction, NORM is related to Prescan Normalize. I assume that the tag under discussion regarding a NonlinearGradientCorrection field would be the DIS2D and DIS3D entries.

[effigies]

If it can't be reliably determined from the DICOM tags, then I agree that we should not set the field. If there are definitive cases where certain values indicate one way or the other, then it would be appropriate to set the field.

Looking at https://cdn0.scrvt.com/39b415fb07de4d9656c7b516d8e2d907/1800000000073846/4a603a47ea58/mr_dicomconformance-00073846_1800000000073846.pdf, ND and DIS2D show up twice and DIS3D once:

• Normalize and Distortion Correction
  • NORM - Normalized Pixel
  • ND - Not distorted Pixel
  • DIS2D - Distorted Pixel and remapped

[...]

• Inline-processing
  • [...]
  • ND - Not Distortion Corrected
  • DIS2D - Distortion Correction 2D
  • DIS3D - Distortion Correction 3D

I don't really understand what "Not distorted Pixel" and "Distorted Pixel and remapped" mean, but it seems likely that they intend the same code to refer to the same process in multiple places. So we may be able to search for these strings in images we're confident are raw Siemens images.

If the DERIVED flag is set, are all bets off? Or can we trust original tags to be preserved but added to?

[CPernet]

correct - ND vs DIS2 or DIS3 is what you want to use (for Siemens)

[neurolabusc]

Sorry, no concrete datasets were provided for validation. The request is to set the NonlinearGradientCorrection field of the BIDS header. Existing versions of dcm2niix does export 0008,0008 as the BIDS "ImageType", so users should be able to query this for DIS3D.

[neurolabusc]

As I noted above, several of the labels used by Siemens were not described by the DICOM specification for Image Type (0008,0008). With XA30, Siemens now uses the private tag 0021,1175 which future releases of dcm2niix report as the BIDS field ImageTypeText (following dicm2nii convention). A sample dataset for this behavior is here. The developmental branch should also correctly detect NonlinearGradientCorrection for Siemens scanners that use DIS2D, DIS3D in either 0008,0008 or 0021,1175. These allow us to reliably detect if NonlinearGradientCorrection is true.

However, I remain unsure how to determine if NonlinearGradientCorrection is false. @CPernet is it safe to assume that ND is always reported when NonlinearGradientCorrection is false?

[CPernet]

so far, curating ~1000 MRI from Trio, Verio, Prisma this has always been the case that ND was the 'standard' image and DIS2D or DIS3D were the corrected images - as reported in ImageType

[neurolabusc]

@CPernet thanks. It is nice to know that 0008,0008 was reliable for various software versions and systems prior to XA30. I have heard direct from Erlangen that moving the DIS2D, DIS3D, and ND values from the public 0008,0008 to the private 0021,1175 was intentional to improve DICOM compliance (as the DICOM specification does not define those values). Therefore, I assume all future XA releases will follow this new pattern.

[mharms]

@effigies I guess this is an issue with the BIDS specification and not dcm2niix, but shouldn't NonlinearGradientCorrection indicate whether a 2D or 3D correction was applied, rather than just a true/false boolean?

[mharms]

Also, for documentation purposes in this thread, do we know if this change started with XA10? Is dcm2niix going to assume it started with XA10 (or just XA30 and onward)?

[neurolabusc]

@mharms my understanding is that XA10,11,20 use 0008,0008. XA30 and later will use 0021,1175.

[mharms]

FWIW, whether XA30 differs from XA10,11,20 in terms of the ImageType reporting wasn't clear to me in the email thread with Erlangen, esp. once you consider the bit about swapping the entries of (0008,0008) and (0021,1175) if using "Interoperability Mode".

[effigies]

@mharms Good point. Proposal here: bids-standard/bids-specification#1160