Any willingness to add Siemens ImaRelTablePosition (0019,1014) to json sidecar?

[imalone]

The Siemens private tag 0019,1014 indicates the relative table position (ImaRelTablePosition), and is useful if performing offline gradwarp correction to scans (essentially allowing conversion from patient to scanner coordinates if the table moves after setting landmarks). It is a three element vector, example 0\0-3 (also included in the CSA header).
I realise it's intentional that not all DICOM values are included in dcm2niix's sidecars, but as this one is useful for preprocessing is there an argument for adding it?

[mharms]

That's the location under VE11 [or equivalently one could use 0051,1012 (TablePositionText) -- e.g., "TP 0"]

The XA30 equivalent is either:
0021,1005 (RelTablePosition) [seems to appear once in a given DICOM]
0021,1159 (RelTablePosition) [seems to appear twice for each slice in an enhanced DICOM]
0021,105f (???, likely analog to VE11's "Table Position Text" -- e.g., "TP 0")

[neurolabusc]

@yarikoptic and @Remi-Gau do you have any opinions on this? It is easy to implement, but I am reluctant to unilaterally add a field that is not in the specification and where the units may be specific to one manufacturer. At the moment dcm2niix populates the JSON with fields described in the BIDS specification as well as other fields unique to dcm2niix. The question I have:

1. should dcm2niix unilaterally include this, or should it be proposed to the BIDS specification, and added to dcm2niix after the BIDS community discusses the necessity and format of this information..
2. Naively, one thinks of a MR table sliding in one dimension (in and out of the bore), however different vendors provide a different number of information on table position. What coordinates should be represent in the output (e.g. three dimensions in DICOM world space coordinates?).
3. @mr-jaemin I am surprised that GE provides 6 parameters for table position - can you explain these numbers and their units? Anecdotally, it seems other vendors have the table center origin as the origin for the head coil, but the extreme values for GE look more like CT table center numbers.

(0043,10b2) LO [956.1\320.1\-17.3125\0\75.3604\58.0479] # GE MR Table Position Information
(0019,1014) IS [0\0\0]                                  # Siemens V* TablePosition
(0021,1005) IS [0\0\0]                                  # Siemens XA TablePosition
(2005,143c) FL 0                                        # Philips MRStackTablePosLong
(2005,143d) FL 0                                        # Philips MRStackTablePosLat
(0065,1023) LO [0]                                      # UIH TablePosition

[mr-jaemin]

[updated on Aug 7, 2024]
GE Private tag (0043,10b2) MR Table Position Information consists of

• isoVectorZ (Distance from ISO to ALIGN)
• landmark
• tablePosition+tableDelta
• dzPETMR
• topOfHead
• distanceFromTopOfHead

Ex) (0043,10b2) LO [956.1\320.1\-17.3125\0\75.3604\58.0479]

GE Private tag (0019,107f) Table delta tableDelta (a.k.a. Table Offset)
Ex) (0019,107f) DS [0.000000]

So, BIDS TablePosition = the 3rd of (0043,10b2) - (0019,107f)

[yarikoptic]

1. should dcm2niix unilaterally include this, or should it be proposed to the BIDS specification, and added to dcm2niix after the BIDS community discusses the necessity and format of this information..

I guess there is no "universal answer" and I guess we are yet to formalize such a workflow. What about:

• If it is some simple common DICOM field uniform across all manufacturers, I would say: dcm2niix includes it under a "standard" name, and proposes inclusion to BIDS specification
• If it is some complicated case like here, without absent uniform specification and possibly spread across multiple fields:
  • if immediate use is desired, I would have extracted them in custom fields with X- prefix (convention present in many standards), e.g. X-SiemensV-TablePosition, X-GE-MR-Table-Position-Information and alike; or even came up with custom X-Dcm2niix-TablePositionInformation with your attempt of harmonization
  • did raise an issue (or ideally a PR) on bids-specification presenting what is known (how represented) and how potentially could be harmonized (e.g. that X-Dcm2niix-TablePositionInformation as a starting point) with hope that it would cover all potentially present metadata
  • after it reaching formalization in BIDS, deprecated X- ad-hoc fields in favor of harmonized BIDS representation.

[imalone]

Thanks for giving this consideration, clearly not simple!

[neurolabusc]

Closing this. Happy to support if it gets a formal BIDS definition.

[po09i]

This would also be a highly requested feature for us as well. @imalone has there been some progress with the BIDS spec folks?

[po09i]

The tag is now getting a formal definition is BIDS: bids-standard/bids-specification#1690

[neurolabusc]

Great. Happy to implement with validation datasets for each manufacturer with known solutions.

[po09i]

Following the discussion in the BIDS specification. We are ready to merge the TablePosition specification. We can therefore start implementing it in dcm2niix. Here are 2 datasets I did in the past where we noted the table movement.

• I uploaded a dataset for Siemens where the table started at isocenter, it was then moved 2cm down (towards the feet in HFS position) and the FOV moved by 2cm with the table. We can therefore see more of the top of the phantom in the "moved" position.
  Expected solution [0,0,0] ->[0,0,-20]

• I also added a dataset for Philips. In this one, the table started at ISO (DICOMS report -0.2mm), the table then moved into the scanner by 6cm when the FOV was changed by 6cm towards the "feet direction" (also HFS). In this acquisition, we can see more of the lower part of the phantom as a result.
  Expected solution [0,0,0.2] ->[0,0,60.3]

These scans were taken a while back so I inferred the table movement from notes and by inspecting the data. Let me know if that fits your validation dataset requirements or if you need more information.

[neurolabusc]

@po09i thanks. Since you have posted open links, am I correct that you consent for sharing these as a validation repository with the BSD-2-Clause license similar to dcm2niix?

@mr-jaemin would it be possible to get a sample dataset of the same object with different table position? This could be a simple low-resolution EPI sequence of a phantom.

[po09i]

@po09i thanks. Since you have posted open links, am I correct that you consent for sharing these as a validation repository with the BSD-2-Clause license similar to dcm2niix?

Yes that's fine

[neurolabusc]

@drmclem the Phiips dataset provided by @po09i is consistent with 2005,143c storing table position in along the axes of the bore (longitude MRStackTablePosLong). However, the value for 2005,143d is implausible for the latitude MRStackTablePosLat also defined here. Does Philips have a formal name and definitions for these private tags?

 (2005,143c) FL -0.200000003                             #   4, 1 Unknown Tag & Data
 (2005,143d) FL 1.69999998e+38                           #   4, 1 Unknown Tag & Data

[po09i]

The documentation I have for tag 2005,143d does refer to the MRStackTablePosLat. The value reported looks very close to the maximum value of a float (~3.4e38). I looked at ~7-8 other Philips acquisition and they all had the same value (~1.7e+38)

[neurolabusc]

@po09i I have added support for Philips, Siemens VE, Siemens XA and GE to the development branch. Please check to ensure this meets your expectations.

[drmclem]

Hi As far as I am aware they are the reported bed movements as actually happened (v requested) - the only system we had in the past which could move the bed L-R was the Panorama open system which is no longer produced so no LR requests can be made and I guess this is just a residue of that. Undocumented private tags can of course change at any time. M From: Chris Rorden ***@***.***> Sent: Thursday, July 25, 2024 10:30 PM To: rordenlab/dcm2niix ***@***.***> Cc: Clemence, Matthew ***@***.***>; Mention ***@***.***> Subject: Re: [rordenlab/dcm2niix] Any willingness to add Siemens ImaRelTablePosition (0019,1014) to json sidecar? (Issue #726) Caution: This e-mail originated from outside of Philips, be careful for phishing. @drmclem<https://github.com/drmclem> the Phiips dataset provided by @po09i<https://github.com/po09i> is consistent with 2005,143c storing table position in along the axes of the bore (longitude MRStackTablePosLong). However, the value for 2005,143d is implausible for the latitude MRStackTablePosLat<https://github.com/xiangruili/dicm2nii/blob/b1224c3486eeac475d30ebae4bc53d917c353dfe/dicm_dict.m#L1234> also defined here<https://github.com/malaterre/dicom-private-dicts/blob/1833fe7683b79e4e2648a199f573c9d1057683e8/PMS-R32-dict.txt#L533>. Does Philips have a formal name and definitions for these private tags? (2005,143c) FL -0.200000003 # 4, 1 Unknown Tag & Data (2005,143d) FL 1.69999998e+38 # 4, 1 Unknown Tag & Data - Reply to this email directly, view it on GitHub<#726 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIRGAT4RO7XC22PMVLRGKADZOFU6TAVCNFSM6AAAAAA2AS6PC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJRGQZDQNRZGE>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

…

________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

[po09i]

@neurolabusc I tested the dev branch. I believe the polarity of the terms are opposite to what the BIDS specification requires (at least for the "z" direction since it's the only data I have). The Siemens dataset gives 20 in the moved position and the Philips dataset gives -60.3 rather than -20 and 60.3 (See #726 (comment)).

[mr-jaemin]

@mr-jaemin would it be possible to get a sample dataset of the same object with different table position? This could be a simple low-resolution EPI sequence of a phantom.

Sure, I will provide GE samples. I was wondering how we validate this information. I am thinking of comparing the table location [in mm] displayed on the system monitor with the DICOM header information.

• Scan at XX mm location landmarked

  • collect sample at center
  • collect another sample at off-center (prescription location moved) so that table is moved

• Second Scan at YY = XX + 50 mm location landmarked

  • collect sample at center
  • collect another sample at off-center (prescription location moved) so that table is moved

Does that sound good?

[neurolabusc]

@mr-jaemin sounds good.

[po09i]

@neurolabusc just making sure you've seen this comment

[neurolabusc]

@po09i seen and deferred. Waiting for a sample dataset from GE, then we can try to close this issue comprehensively.

[mr-jaemin]

GE validation datasets collected by Sagar, generously provided by Emory SPARC (SIGNA Premier). Please allow some time for me to digest and summarize the experiment. Will share soon.

[mr-jaemin]

@neurolabusc Any existing repository for TablePosition validation datasets?

[neurolabusc]

@mr-jaemin I have added Siemens and Philips images from @po09i here dcm_qa_table. I also note that dcm_qa_ge has images with different table positions that the latest version of dcm2niix detects. However, it would be ideal to make sure that we have the polarity correct. For example, for a HFS participant, as the individual's feet move closer to the isocenter (so Z is increased), the isocenter origin of the image moves toward the feet (so Z decreases). Note things reverse for a FFS participant.

[mr-jaemin]

@neurolabusc I have added GE images with different table positions (two landmark locations + three different SI scan volumes) in both FFS and HFS currently here dcm_qa_table and submitted PR to your dcm_qa_table. Also, documented here GEHC_BIDS_TablePosition_validation.pdf for experiment setup, DICOM tags, and results.

For GEHC. I observed that

• After landmarking & pressing "advance to scan", table moves such that landmark location is at the isocenter of the magnet.
• In general, table is moved such that center of prescription is at the isocenter (for example, +10mm)
• DICOM private tag (0043, 10b2) reports both landmark and table position (including table offset, see below) in world coordinates in mm, which is consistent with BIDS TablePosition's definition.
• So, this information is valid and accurate for both FFS and HFS,
• For most MR scans, the table offset is 0, but there are some normal situations when the table offset is non-0 (see GEHC_BIDS_TablePosition_validation.pdf for details)
• DICOM private tag (0019, 107f) report this Table delta (a.k.a Table Offset)
• BIDS TablePosition can be calculated from (0043,10b2) and (0019,107f) such that
  • BIDS TablePosition = the 3rd value of (0043,10b2) – the value of (0019,107f)

[mr-jaemin]

For GE, in research mode, Table Delta can be prescribed including fMRI/DTI as shown below. Updated this info GEHC_BIDS_TablePosition_validation.pdf on Aug 8, 2024

[neurolabusc]

@mr-jaemin I have merged your request. The final step is to ensure that the polarity of the final (Z) direction of the TablePosition is reported correctly. As @po09i noted, for Philips and GE the current development branch of dcm2niix reports the incorrect polarity. In other words, as a HFS participant is moved further into the bore of the scanner (Z+), the scan origin is moved toward the feet (Z-). If the same logic works for GE, we can apply a universal fix by adjusting line 1679 of nii_dicom_batch.cpp from:

if (d.CSA.tablePos[0] > 0.0)
	fprintf(fp, "\t\"TablePosition\": [\n\t\t%g,\n\t\t%g,\n\t\t%g\t],\n", d.CSA.tablePos[1], d.CSA.tablePos[2], d.CSA.tablePos[3]);

to read

if (d.CSA.tablePos[0] > 0.0)
	fprintf(fp, "\t\"TablePosition\": [\n\t\t%g,\n\t\t%g,\n\t\t%g\t],\n", d.CSA.tablePos[1], d.CSA.tablePos[2], - d.CSA.tablePos[3]);
// n.b. issue726 Table Position Z-polarity of BIDS opposite of DICOM (as HFS table moves further into bore [Z+], the origin moves toward feet [Z-])

Can you confirm that this is the case for GE as well?

[mr-jaemin]

@neurolabusc No, for GE, the current development branch of dcm2niix (v1.0.20240731) report the correct polarity for both HFS and FFS datasets. The last step for GE would be incorporating the Table Delta (0019,107f) for completeness as explained above and also shown below. Although I don't have a sample with non-0 Table Delta (all of dcm_qa_table curently with 0 Table Delta), I confirm this formula from the code:

BIDS TablePosition = the 3rd value of (0043,10b2) – the value of (0019,107f)

I am happy to submit the PR for this.

[mr-jaemin]

@neurolabusc Submitted the PR (#850)
BIDS TablePosition = the 3rd value of (0043,10b2) – the value of (0019,107f)

Please review the PR

[neurolabusc]

@po09i do you want to test the latest commit to the development branch and the dcm_qa_table validation tests. If this passes your review, please close this issue. Thanks for your work on this.

Moving forward, as @dclunie noted we should be responsive if any manufacturer implements the public tag Table Position (0018,9327) instead of private tags.

[po09i]

I reviewed the datasets and I believe everything is good to go. I noticed that there are negative 0s so I'm pointing it out if that is something you would like to fix. I personally do not mind them. Thanks @neurolabusc and @mr-jaemin for your help.

Moving forward, as @dclunie noted we should be responsive if any manufacturer implements the public tag Table Position (0018,9327) instead of private tags

Agreed

[po09i]

FYI I can't close the issue since it was @imalone who opened it.

[imalone]

Amazing, thank you.