GE shims

[mharms]

What do you think about adding the following fields from GE DICOMs to ShimSettings:

Example shim values:
# gradient offset in X
(0x0043,0x1002) SS 2 [123]
# gradient offset in Y
(0x0043,0x1003) SS 2 [-21]
# gradient offset in Z
(0x0043,0x1004) SS 2 [457]

Another potentially very useful field that someone at GE clued me in to is (0043,1095):

Another bit of information perhaps relevant to this line of questioning, the “prescan use string” indicates what series the shim values were copied from (in case Auto or No is specified), in this example, series 3:
# Prescan Reuse String
(0x0043,0x1095) LO 36 [TG/s2,CF/s3,AS/s3,RN/s1,MD/s1,Cal/s3]

[neurolabusc]

@mr-jaemin do you have any thoughts on storing these private tags in the BIDS JSON. Is the definition of these private tags stable across GE software versions?

[mr-jaemin]

I confirmed that these tags are captured in DCM, for example SIGNA Premier RX29.1

Attribute Name	Tag	VR	VM
Gradient offset in X	(0043,1002)	SS	1
Gradient offset in Y	(0043,1003)	SS	1
Gradient offset in Z	(0043,1004)	SS	1
Prescan Reuse String	(0043,1095)	LO	1

I believe that these tags are stable across GE software versions. At least, I confirmed the code unchanged between DV25 and MR30.

[mr-jaemin]

I was wondering how this information will be utilized.

[mharms]

To check whether the shims are changing between scans, and to understand the "Prescan" better.

[captainnova]

They apparently go back to at least GE software version 15, in a FLAIR from November 2009. Someone here uses shim settings while calculating CBF from GE 3D pcASL, but I'm not at all familiar with it. Rob

…

On Thu, Jun 2, 2022, 9:16 PM Jaemin Shin ***@***.***> wrote: I confirmed that these tags are captured in DCM, for example SIGNA Premier RX29.1 <https://www.gehealthcare.com/-/jssmedia/documents/us-global/products/interoperability/dicom/magnetic-resonance/239484efd3fa5f2b6ae537660258547aff3gehcdicomconformancemrsignadiscoveryoptimarx291rx273dv291dv282dv2.pdf?rev=-1&hash=FC505F004AD6E561452A84BBCDC0DDB4> Attribute Name Tag VR VM Gradient offset in X (0043,1002) SS 1 Gradient offset in Y (0043,1003) SS 1 Gradient offset in Z (0043,1004) SS 1 Prescan Reuse String (0043,1095) LO 1 I believe that these tags are stable across GE software versions. At least, I confirmed the code remained same from DV25 (oldest I can check for now). — Reply to this email directly, view it on GitHub <#608 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADY6J2IP235N2FYQK33PNZTVNFTIZANCNFSM5XVTCS6Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[neurolabusc]

@captainnova and @mharms can you confirm you are happy with the latest addition to the development branch (v1.0.20220606). For GE MRI, the BIDS json file will be populated with the following tags:

	"ShimGradientX": 3,
	"ShimGradientY": 5,
	"ShimGradientZ": 65524,
	"PrescanReuseString": "TG/s3,RN/s1",

Alternatively, we could provide this as an array, to match the output from Siemens scanners:

	"ShimSetting": [
		3,
		5,
		65524	],
	"PrescanReuseString": "TG/s3,RN/s1",

However, the GE DICOMs have three unique DICOM tags, so listing three values in the BIDS keeps the correspondence between the DICOM and BIDS tags. I could go either way on these representations, so tell me if you have a strong opinion on this. I would also appreciate thoughts from @effigies as he is the final dcm2niix arbitrator for all things BIDS.

[mharms]

@neurolabusc: I don't feel the need to explicitly run this, unless you really want me to. Personally, I think it makes sense to include the GE shims values as part of the already existing ShimSetting field/array for Siemens, since they are capturing the same conceptual thing. Plus, easy to add higher-order shims to the ShimSetting array if GE populates those values into the DICOMs at some point. I'm not finding the word shim anywhere in the current BIDS specification.

[pvelasco]

heudiconv uses the ShimSetting when trying to automatically populate the IntendedFor field, so it would work on GE files without any changes if you wrote the GE shims to the ShimSetting array. But if keeping the correspondence with the DICOM header is preferred, heudiconv can be easily modified, so it is fine either way...

[captainnova]

I will try to run the development branch with my collection of test data tomorrow and take a look at whether the shim setting appears to be behaving in the json files. But I don't have much of an opinion on using the shim settings, so feel free to go ahead without me. Rob

…

On Mon, Jun 6, 2022, 2:47 PM Chris Rorden ***@***.***> wrote: @captainnova <https://github.com/captainnova> and @mharms <https://github.com/mharms> can you confirm you are happy with the latest addition to the development branch (v1.0.20220606). For GE MRI, the BIDS json file will be populated with the following tags: "ShimGradientX": 3, "ShimGradientY": 5, "ShimGradientZ": 65524, "PrescanReuseString": "TG/s3,RN/s1", Alternatively, we could provide this as an array, to match the output from Siemens scanners: "ShimSetting": [ 3, 5, 65524 ], "PrescanReuseString": "TG/s3,RN/s1", However, the GE DICOMs have three unique DICOM tags, so listing three values in the BIDS keeps the correspondence between the DICOM and BIDS tags. I could go either way on these representations, so tell me if you have a strong opinion on this. I would also appreciate thoughts from @effigies <https://github.com/effigies> as he is the final dcm2niix arbitrator for all things BIDS. — Reply to this email directly, view it on GitHub <#608 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADY6J2PIQYGKYSUUTZ5ECRLVNZIUTANCNFSM5XVTCS6Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[effigies]

BIDS currently has nothing to say about shims so I would follow what people who use these metadata would find more useful. I don't really have a use case in mind, but my instinct is that an array of numbers is simpler than separate keys.

Looking through existing fields in MR, I see only one thing that has a value per axis:

Key name	Requirement level	Data type	Description
AcquisitionVoxelSize	RECOMMENDED	array of numbers	An array of numbers with a length of 3, in millimeters. ...

And none with a field per axis.

If someone has a compelling reason to split, that seems okay to me, and if not my slight preference is towards one field.

[captainnova]

I will try to run the development branch with my collection of test data tomorrow

I guess it's been a while since I've compiled dcm2niix - unfortunately libstdc++-static has evaporated from our CentOS build environment. I asked our sysadmins about it and hopefully they can get to it tomorrow. But I'm going to bail on running a test today, sorry.

[captainnova]

v1.0.20220606 (git pulled yesterday) worked well with my test suite.

I happened to prefer the array form of ShimSettings instead of _x, _y, _z, but now that I see GE and Siemens .jsons side by side it's obvious that it's an absolute necessity. (Siemens has 8, and as @mharms noted there's nothing to stop any manufacturer from adding higher order terms later.)

[mharms]

I just discovered that there appears to be a data type issue (signed vs. unsigned) on the newly reported GE linear shims.
e.g.,
Here are the values from a scan as reported by dcmdump:

(0043,1002) SS -1 
(0043,1003) SS 5 
(0043,1004) SS -6

And here is what dcm2niix returned for that same scan:

	"ShimSetting": [
		65535,
		5,
		65530	],

Per a GE DICOM conformance document that I found, the (0043,1002-1004) fields have a VR of SS, so the signed values returned by dcmdump seem more likely to be the correct interpretation.

[mr-jaemin]

I confirmed the SS from the DCS SIGNA Premier RX29.1

Attribute Name	Tag	VR	VM
Gradient offset in X	(0043,1002)	SS	1
Gradient offset in Y	(0043,1003)	SS	1
Gradient offset in Z	(0043,1004)	SS	1
Prescan Reuse String	(0043,1095)	LO	1

[neurolabusc]

@mharms well spotted - latest commit supports signed values.