bids json output carries spurious -" entry

[yarikoptic]

not sure what is happening besides being Friday -- I think I have ran conversion on those before and didn't observe such behavior...

$> /tmp/dcm2niix -b y -z i -x n -t n -m n -f fmap -o  /tmp/out -s n -v n /mnt/btrfs/dbic/inbox/DICOM/2016/12/04/A000121/006*fmap*
Chris Rorden's dcm2niiX version 1Jan2017 (64-bit Linux)
customOutDir set to /tmp/out
inDir /mnt/btrfs/dbic/inbox/DICOM/2016/12/04/A000121/006-fmap_acq-2.4mm
outDir /tmp/out
outDir(again) set to /tmp/out
Warning: Checking existence of output folder '/tmp/out'
Found 64 DICOM image(s)
slices not stacked: echo varies (TE 7.38, 4.92; echo 2, 1)
Dims 90 90 61 1 1
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
 Distance from first slice:
dx=[0 2.4 4.8 7.2 9.59999 12 14.4 16.8 19.2 21.6 24 26.4 28.8 31.2 33.6 36 38.4 40.8 43.2 45.6 48 50.4 52.8 55.2 57.6 60 62.4 64.8 67.2 72 74.4 76.8 79.2 81.6 84 86.4 88.8 91.2 93.6 96 98.4 100.8 105.6 110.4 112.8 115.2 117.6 120 122.4 124.8 127.2 129.6 132 134.4 136.8 139.2 141.6 144 146.4 148.8 151.2]
Convert 61 DICOM as /tmp/out/_e2fmap (90x90x61x1)
slices not stacked: echo varies (TE 4.92, 7.38; echo 1, 2)
Dims 90 90 3 1 1
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
 Distance from first slice:
dx=[0 33.6 38.4]
Warning: Weird CSA 'ProtocolSliceNumber' (29): SPATIAL, SLICE-ORDER AND DTI TRANSFORMS UNTESTED
Convert 3 DICOM as /tmp/out/fmap (90x90x3x1)
Conversion required 0.172284 seconds.

$> cat /tmp/out/*json
{
	"Manufacturer": "Siemens",
	"ManufacturersModelName": "Prisma",
	"ProcedureStepDescription": "XXX",
	"ProtocolName": "fmap_acq-2.4mm",
	"ImageType": ["ORIGINAL", "PRIMARY", "M", "ND", "NORM"],
	"AcquisitionDateTime": "2016-12-04T13:49:17.015625",
	"MagneticFieldStrength": 3,
	"FlipAngle": 60,
	"EchoTime": 0.00738,
	"RepetitionTime": 0.675,
-"
}
{
	"Manufacturer": "Siemens",
	"ManufacturersModelName": "Prisma",
	"ProcedureStepDescription": "XXX",
	"ProtocolName": "fmap_acq-2.4mm",
	"ImageType": ["ORIGINAL", "PRIMARY", "M", "ND", "NORM"],
	"AcquisitionDateTime": "2016-12-04T13:49:16.156250",
	"MagneticFieldStrength": 3,
	"FlipAngle": 60,
	"EchoTime": 0.00492,
	"RepetitionTime": 0.675,
-"
}

happens similar to non problematic ones :-/

[neurolabusc]

Now fixed - regression due to sloppy fix for #79. Perhaps @chrisfilo wants to comment on how BIDS should handle converted images where the slice encoding direction or polarity is unknown. In the past the user would see one of the four options
i, i-, j, j-
The issue here is for some images these values are unknown. So in the past the value 'i' simply meant "not known to be j" and the value "-" meant "not known to be positive". The latest release provides more options
i, i-, i?, j, j-, j?, ?, ?-, ??
I wonder if we should simply omit this field if EITHER encoding direction or encoding polarity is unknown.

Alternatively, would the output be clearer if the positive polarity was displayed if detected:
i+, i-, i?, j+, j-, j?, ?+, ?-, ??

I do not have a strong preference, so will implement whatever @chrisfilo suggests.

@yarikoptic - would you send me a sample of one of these images for me to look at - I am surprised that it did not provide a phase encoding direction (0x0018,0x1312 should be ROW or COL). I would expect PAR/REC files to fail, but this parameter should be recorded in DICOM images.

[chrisgorgo]

On Fri, Jan 13, 2017 at 3:10 PM, Chris Rorden ***@***.***> wrote: Now fixed - regression due to sloppy fix for #79 <#79>. Perhaps @chrisfilo <https://github.com/chrisfilo> wants to comment on how BIDS should handle converted images where the slice encoding direction or polarity is unknown. In the past the user would see one of the four options i, i-, j, j- The issue here is for some images these values are unknown. So in the past the value 'i' simply meant "not known to be j" and the value "-" meant "not known to be positive". The latest release provides more options i, i-, i?, j, j-, j?, ?, ?-, ?? I wonder if we should simply omit this field if EITHER encoding direction or encoding polarity is unknown.

This is the best course of action for now.

Alternatively, would the output be clearer if the positive polarity was displayed if detected: i+, i-, i?, j+, j-, j?, ?+, ?-, ??

I'll float those around on the bids-discussion mailing list to see what the community thinks.

…

I do not have a strong preference, so will implement whatever @chrisfilo <https://github.com/chrisfilo> suggests. @yarikoptic <https://github.com/yarikoptic> - would you send me a sample of one of these images for me to look at - I am surprised that it did not provide a phase encoding direction (0x0018,0x1312 should be ROW or COL). I would expect PAR/REC files to fail, but this parameter should be recorded in DICOM images. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#83 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOkp1u5eDwJekz5PFG6HRJlP7T9_VR7ks5rSAR_gaJpZM4LjU5_> .

[yarikoptic]

I would need to ask since data is not mine... What about me collecting some data on a phantom using the same parameters on Monday and then making it into a regression test suite? ;-)

[neurolabusc]

@yarikoptic that would be great. Ideally, it would be great if you could donate the set to the Rosetta BIT project. There are already a lot of images here, here, and here we could use. I do think we could make a simple project with a repository to test a huge number of files. I do think we would want to make this separate from this project so general users would not need to face huge downloads. As I recall, there are also issues to repository sizes on github, so perhaps this would be a gitlab or nitric download. Would you be willing to develop and maintain a test suite?

@chrisfilo - as you requested, the latest version only saves the BIDS "PhaseEncodingDirection" tag if BOTH the direction and polarity are known. As a consequence, I am pretty sure this tag will never be generated for Philips and GE systems (as there is not a common DICOM tag for polarity, I peak at the Siemens CSA header). Since you work near a GE center, perhaps you want to see if GE uses a private DICOM tag to store polarity. Perhaps an alternative would be to have BIDS store separate tags, one for direction (i,j for ROW,COL) and one for polarity (+,-).

I note that the dicm2nii matlab code does detect phase encoding polarity for both GE and Philips by reading private tags (readingProtocolDataBlock and MRStackPreparationDirection respectively). This does not look like a simple solution, so would be great to have sample datasets and ideally someone who is willing to implement and maintain support for this feature.

[yarikoptic]

it is weird -- I have finally had a chance to get some phantom data, now uploaded to http://datasets.datalad.org/?dir=/dicoms/dartmouth-phantoms/bids_test5-20170120/phantom-1 but I don't see the same effect, so I guess I have screwed up to replicate although used the same sequences. May be it was due to crafty positioning of the scanning FOV.

[yarikoptic]

oh -- right after I have sent it -- I remembered that I had another copy of a binary sitting in /tmp -- so it did replicate using it:

(venv)mvdoc@smaug /tmp $ rm -rf nonexisting; mkdir nonexisting; /tmp/dcm2niix -b y -z i -x n -t n -m n -f fmap -o /tmp/nonexisting -s n -v n bids_test5-20170120/phantom-1/006-fmap_acq-2.4mm/                                         
Chris Rorden's dcm2niiX version 1Jan2017 (64-bit Linux)
customOutDir set to /tmp/nonexisting
inDir bids_test5-20170120/phantom-1/006-fmap_acq-2.4mm/
outDir /tmp/nonexisting
outDir(again) set to /tmp/nonexisting
Warning: Checking existence of output folder '/tmp/nonexisting'
Found 128 DICOM image(s)
slices not stacked: echo varies (TE 4.92, 7.38; echo 1, 2)
Convert 64 DICOM as /tmp/nonexisting/fmap (90x90x64x1)
slices not stacked: echo varies (TE 7.38, 4.92; echo 2, 1)
Convert 64 DICOM as /tmp/nonexisting/_e2fmap (90x90x64x1)
Conversion required 0.186414 seconds.
(venv)mvdoc@smaug /tmp $ cat nonexisting/*json
{                        
	"Manufacturer": "Siemens",
	"ManufacturersModelName": "Prisma",
	"ProcedureStepDescription": "Heatherton_Stanger_1004_ontrack",
	"ProtocolName": "fmap_acq-2.4mm",
	"ImageType": ["ORIGINAL", "PRIMARY", "M", "ND", "NORM"],
	"AcquisitionDateTime": "2017-01-20T85:02:7.031250",
	"MagneticFieldStrength": 3,
	"FlipAngle": 60,
	"EchoTime": 0.00738,
	"RepetitionTime": 0.675,
-"
}
{
	"Manufacturer": "Siemens",
	"ManufacturersModelName": "Prisma",
	"ProcedureStepDescription": "Heatherton_Stanger_1004_ontrack",
	"ProtocolName": "fmap_acq-2.4mm",
	"ImageType": ["ORIGINAL", "PRIMARY", "M", "ND", "NORM"],
	"AcquisitionDateTime": "2017-01-20T85:02:6.351562",
	"MagneticFieldStrength": 3,
	"FlipAngle": 60,
	"EchoTime": 0.00492,
	"RepetitionTime": 0.675,
-"
}
(venv)mvdoc@smaug /tmp $ nonexisting/*json
(venv)mvdoc@smaug /tmp $ /tmp/dcm2niix --help
Chris Rorden's dcm2niiX version 1Jan2017 (64-bit Linux)
Example output filename: '/fmap.nii.gz'

so I guess it is all good for a test/more troubleshooting

[neurolabusc]

Thanks for the sample dataset. This demonstrates that the regression from #79 is fixed. Further, dcm2niix seems to be getting the phase direction and polarity correctly for all 3D sequences. The issue of not encoding phase direction and polarity is specific to the 2D localizer sequence where orthogonal slices are acquired as a single series (and these are not suitable for undistortion).