Inconsistent reverse B0 (PA) identification

Description

Although the filenames produced by dcm2niix to transform DWI DICOM files into NIfTI files identifies files and labels them as being reverse B0 (i.e. PA) files, it seems not to be in agreement when visually inspecting the volumes.

Also, the PhaseEncodingDirection tag value in the JSON file created by dcm2niix for the reverse B0 files (whether they contain the direction label in the filename or not), seems not be consistent across studies

Scanner manufacturer and model

Scanner manufacturer and model as written in the JSON file tags Manufacturer and ManufacturersModelName produced by dcm2niix, forward/reverse B0 filename relevant part generated by dcm2niix, PhaseEncodingDirection tag value in the corresponding JSON files and AP/PA presence by visual inspection:

1. Philips TrioTim ; B02_AP: j- | B03_PA: j ; true PA: B03_PA
2. Philips Ingenia ; b0_AP: j | no PA filename produced ; true PA
3. Philips Achieva ; b0: j (no direction tag in filename) ; not a PA
4. Philips Ingenia ; b0_AP: j | no PA filename produced ; true PA
5. Philips Achieva ; AP: j | no PA filename produced ; not a PA
6. Siemens TrioTim ; B02_AP: j- | B03_PA: j ; true PA: B03_PA
7. Siemens TrioTim ; B02: j- | B03: j | (no AP/PA filename produced) ; true PA (B03)
8. Siemens TrioTim ; B02_AP: j- | B03_PA: j ; true PA: B03_PA
9. Siemens Prisma ; AP: j- | PA; j ; not a PA
10. Siemens Prisma ; b0_1: j- | b0_2: j- ; not a PA
11. Siemens Skyra ; B02_AP: j- | B03_PA: j- ; not a PA
12. Siemens Skyra ; B02_AP: j- | B03_PA: j- ; not a PA
13. Siemens Prisma ; b0_1: j- | b0_2: j- ; not a PA
14. Philips Intera ; b0: j (no direction tag in filename) ; not a PA
15. Philips Intera ; b0: j (no direction tag in filename) ; not a PA
16. Siemens Prisma** ; B02_AP: j- | B03_PA: j ; true PA: B03_PA
17. Siemens TrioTim ; B02: j- | B03: j ; true PA B03
18. GE Signa Pioneer ; (no AP/PA/B0 filename produced) ; 
      true PA (present in a file *EP_SE* file)

dmc2niix and OS version

dcm2niiX version v1.0.20181125 GCC5.4.0 (64-bit Linux)

Command used when doing the DICOM to NIfTI conversion

dcm2niix -o $study_nifti_out_path -f %i_%p_%q $study_dicom_path

executed inside a loop over all the DICOM folders, and where $study_nifti_out_path is my output path for the dcm2niix generated NIfTI files for each study, and $study_dicom_path is the path of each DICOM folder where the original data files live.

The short version:

The file name you are using (%i%p%q) should be the PatientID_ProtocolName_AcquisitionNumber. Note that this does not explicitly tell you anything about phase encoding direction unless the person who set up the protocol on the console decided to enter this in the protocol name. Based on your description, I think most of yours had the phase encoding axis added to denote these were acquired in the AP not RL direction. Based on your output, this person was probably not trying to report the phase encoding polarity (e.g. A->P vs P->A). When dcm2niix inserts protocol name into a file name it rote copies 0018,1030 into the filename. The protocol name could be anything ("epi", "MyScan", etc).
The dcm2niix json tag "PhaseEncodingDirection" follows the BIDS format, which reports whether the the DICOM tag In-plane Phase Encoding Direction (0018,1312) was COLS (j) or ROWS (i). For axial scans COLS would be R<>L and ROWS would be A<>P. Note that for your sample dcm2niix is able to always determine this accurately (all your scans are A<>P). This is unsurprising, as we are able to use a known DICOM tag. However, working out the phase encoding polarity (blip up or blip down) is complicated by two factors: there is no formal DICOM tag for this, and the BIDS format simply provides a "-" modifier to report reversed blip. Therefore the BIDS tag "PhaseEncodingDirection": "j" is used both for known polarity and when polarity is unknown. This is unfortunate, but it reflects a conscious decision of the BIDS team to keep backward compatibility. Since dcm2niix is a BIDS compliant tool, you need to lobby the BIDS team if you want to change this behavior.
In hindsight, it would have been nice to include two tags: PhaseEncodingAxis and PhaseEncodingPolarity. The Axis would tell us if the axial scan had R<>L or A<>P phase encoding and could always be determined, while the Polarity would only be populated if the phase encoding polarity could be detected, and would disambiguate blip direction (blip up or blip down). However, the BIDS team discourages storing redundant data twice (avoiding name conflicts) and strives for backwards compatibility. The combination of these laudable goals means we stick with the single PhaseEncodingDirection tag. Therefore, dcm2niix does as much as it possibly can, but in some cases the user will still need to determine phase encoding polarity.
For Siemens data we can virtually always determine the PE polarity by reading the proprietary CSA DICOM tag. With a pair of data acquired with the same sequence but reversed phase encoding, we are confidently able to detect the polarity reversal. Since BIDS was designed by people at Siemens centers, I think this explains the original PhaseEncodingDirection definition. While there might be custom sequences that define the meaning of the polarity differently, within a sequence we should be fine. The new wrinkle to this is the new XA10 format Siemens released with their new Vida scanner. This scanner removes the CSA header entirely and does not include any of the rich meta data we are used to preserving. You will note the BIDS files created when dcm2niix encounters a XA10 file are very spartan: this reflects a weakness in the base image format not a problem with dcm2niix. If you are using an XA10 system for research I would lobby your Siemens Research Collaboration Manager to provide richer sequence data. Click here for Siemens specific details
For GE scanners, there is no official way to determine phase encoding polarity. However, recent versions (v1.0.20181125 and later) do include a reverse engineering that attempts to decipher both phase encoding polarity and slice order. If phase encoding polarity can be deciphered, dcm2niix populates an non-BIDS tag in the JSON header that will read "PhaseEncodingPolarityGE": "Unflipped" or "PhaseEncodingPolarityGE": "Flipped". I realize this tag is against the nature of the BIDS spirit to report things only once. However, since I do not have access to GE hardware, and the detection algorithm is unable to determine this property for some systems, I think this flag helps the user realize when we think the polarity is meaningful. If you have a GE system, I would ask you to contact your vendor and lobby them to report these important sequence details in a simple method. Full details on GE DICOM conversion is here.
For Philips data, the DICOM data do not store phase encoding polarity. This is not a failure of dcm2niix: there is simply no method to determine polarity from the header. If you have a Philips scanner I would ask you to contact your vendor and lobby them to report these important sequence details. Full details on Philips DICOM conversion is here.
As an aside, some older Siemens sequences required the user to manually swap phase encoding polarity prior to each scan if you wanted to copy slice references. This was fairly laborious and provided a moment where an error could be made. Fortunately, dcm2niix can reliably detect the relative phase encoding for these scans, so you can determine what was actually acquired rather than intended. For recent releases, one can embed the PE polarity in the sequence. Just make sure whoever is acquiring the sequence knows that no manual intervention is intended. One must break the habit of manually adjusting phase encoding.
It should be noted, that the default order of rows in DICOM and NIfTI are reversed. DICOM rows go from top-to bottom (like we read English), while in NIfTI the low rows are near the bottom with values ascending as we go up (the way we draw a cartesian graph). If the raw DICOM data is converted, images will appear upside down in tools that ignore the S-Form (like the deprecated FSLview). This flip modifies the S-Form so images appear fine in NIfTI savvy viewers (e.g. MRIcroGL, SPM, FSLview, etc). However, be aware that the BIDS tag PhaseEncodingDirection specifies the direction in image space. This explains why a axial A->P scan from a Siemens scanner reports "PhaseEncodingDirection": "j-" when you might expect that from a P->A scan. I STRONGLY discourage this, but you can use the hidden dcm2niix conversion flag -y y to flip the y-coordinate (so the raw DICOM rows will be copied) and this will necessarily flip the polarity of all image-space row metrics (bvecs, phase encoding polarity).
As an aside, I note that you are using acquisition number in the output name. This is actually a hidden flag with the typical compile of dcm2niix. Specifically, by default dcm2niix stacks images of different acquisition numbers, therefore the reported acquisition number will be the first acquisition in the file, but there may be multiple acquisitions represented in a single file. I would generally suggest you use series (%s) number instead, as this will be consistent for all images in a file. The only case where acquisition number makes sense (and where the flag is unhidden) is if you recompile dcm2niix to segment different acquisitions into different files. The only case I know where this is done is with some unusual research CT sequences.
I am sorry this is as complicated as it is. I have made every attempt to make things as simple as possible while dealing with the images provided by different vendors and obeying the BIDS guidelines.

Hi Chris. I'm confused. I thought it had been decided back here https://github.com/rordenlab/dcm2niix/issues/163#issuecomment-380887134 that PhaseEncodingDirection should only be used if the polarity is known (which is consistent with the intention of the BIDS spec). i.e., PhaseEncodingDirection should not be used if the polarity is NOT known. Did something change since that discussion?

@mharms yes, thanks for your correction. Recent versions of dcm2niix will use the tag PhaseEncodingAxis instead of PhaseEncodingDirection when the phase encoding polarity is unknown. Since I do not have access to hardware that makes the problematic images, I have little experience with these.

if any user has access to Philips hardware (or a Siemens Vida XA10), it would be great to have enhanced DICOM datasets that illustrate diffusion gradient direction and phase encoding for this equipment. There are a few DICOM images for this equipment. However, the is nothing equivalent to the Siemens (pre-XA10), GE or UIH validation DICOM datasets. These reference datasets are intentionally very small (low spatial resolution, very few volumes) that are run with every commit of dcm2niix code. Given that enhanced DICOM is very vulnerable to disruption by non-enhanced aware tools (e.g. attempts to anonymize or convert to implicit VR can corrupt these datasets), it would be really useful to have reference examples of what these images should look like.

@neurolabusc thanks for the detailed answer !

Well, I see that this is harder than I thought, and that dcm2niix makes as best as it can to get the information as accurately as vendor's provide. I appreciate the effort.

A few comments:

For axial scans COLS would be R<>L and ROWS would be A<>P. Note that for your sample dcm2niix is able to always determine this accurately (all your scans are A<>P).

Does this mean for any A<>P blipup/blipdowns I should see the InPlanePhaseEncodingDirectionDICOM tag in the JSON have the ROW value? I'd dare to say that this is not consistent with what I see.
As for the PhaseEncodingAxis tag, if PhaseEncodingDirection will have the same value when the phase polarity is known or unknown, then how do I know if I need to have a look/trust the PhaseEncodingAxis tag value to tell a P->A from an A->P?
Correct me if I'm wrong, but whether we have one or a thousand subjects, we'd need to open their blipup/blipdowns one by one and rely on some expert to tell whether it's an A->P, a P->A or neither.

Now the question I have is whether I can be confident that if a P->A blipup/blipdown acquisition is present in the DICOM files dmc2niix will name it as *b0* or *B0*. I am sorry if this has an evident answer.
As for the file naming, I appreciate the comment. If I'm not mistaken, and according to the NITRC docs, %q is the sequence name, not the acquisition number. A random filename I got looks like this: {subject_ID}_DTI_b0_AP_SENSE_SE.nii.gz. As you mention, I do not think the acquisition number is meaningful to my purposes. Finally, according to the DICOM standard, the corresponding tag for the SequenceName would be 0018,0024 (which is what I meant to have with %q), in which case the dcm2niix NITRC documentation would not be accurate. Please, correct me if I'm wrong.

Mea culpa, %u is acquisition number and %q is sequence name ScanningSequence (0018,0020). %z is SequenceName (0018,0024). dcm2niix simply transcribes the values rote, and you will want to work out a reliable algorithm for detecting these scans. For your sample, b0 might be sufficient, but looking at my Siemens Prisma/Trio data our DWI images are often ep_b0, but can vary (e.g. epse2d, ep_b5).
As I noted, for Siemens and GE scans you should be pretty confident of detecting the blip-up and blip-down pairs within a session, since both images will use the same sequence (caveats: not Siemens XA10, GE scanners with software where the reverse-engineered detection works). With Philips images this information is simply not stored in DICOM data. Be aware that for TOPUP/Eddy it does not actually matter that you accurately detect the direct blip-up and blip-down: you only need to detect the two series have DIFFERENT blip directions. TOPUP/Eddy will generate the same correction (just reverse magnitude, which you apply in reverse order, to get the same transformed data). A conventional 2D EPI scan will always have a phase encoding axis and polarity, so none is not an option. In theory, a GE user might acquire 2D slices using spiral in and spiral out. I do think you should be able to work out a pretty straightforward algorithm for your Philips data to detect pairs of diffusion data with different directions. Likewise, other EPI scans (ASL, fMRI, resting state) will report phase encoding direction bu will not be b0, though you may want to ignore those scans.
- As @mharms noted, the recent versions should report PhaseEncodingDirection when both direction and polarity can be determined and PhaseEncodingAxis when the polarity is unknown. However, be aware that I do not have access to Philips or GE hardware, and people generally only share data when things go wrong. I have literally dozens of examples of Philips enhanced DICOMs that were mangled by other tools, but not a single reference set of what a pure Philips enhanced DWI scan looks like. I do my best to provide a robust tool, but my coverage is limited and this supporting this software must take a back seat to the my other responsibilities.
- Assuming Axial slices, for AP axis you will see "InPlanePhaseEncodingDirectionDICOM": "COL" and for RL you will see "InPlanePhaseEncodingDirectionDICOM": "ROW". Click here for examples from Siemens and Siemens/GE.

Thanks for all this supplementary explanations @neurolabusc . I appreciate the time you've taken to answer.

I see that the question is nontrivial and it requires lots of experience. I'll let you know if I come to some meaningful conclusion or if I can somehow improve dcm2niix.

In the meantime, I'm closing the issue then.

rordenlab / dcm2niix