if the array contains no sub-arrays, it'll concatenate into a single comma-separated list and insert the information as a single header entry;
if the array contains only sub-arrays, it'll concatenate each sub-array into a comma-separated list

With #1735 (specifically here) and #1738 I found that in order to have the JSON export operate as intended for slice timing information extracted from DICOM, such array data needed to be saved as space-separated rather than comma-separated in the header. If it's comma-separated, the JSON .dump() function generates a list of lists with one entry (demonstration in #1738). What does the JSON data output by dcm2niix look like with respect to #1738?

This is all based on on-going discussions with Finn Lennartsson - might be worth involving him in the discussion, but I don't think he has a GitHub account...

In any case, this is what dcm2niix produces for that entry:

"SliceTiming": [
0,
2.7625,
1.745,
0.7275,
3.49,
2.4725,
1.455,
0.4375,
3.2,
2.1825,
1.165,
0.145,
2.9075,
1.89,
0.8725,
3.635,
2.6175,
1.6,
0.5825,
3.345,
2.3275,
1.31,
0.2925,
3.055,
2.035,
1.0175,
0,
2.7625,
1.745,
0.7275,
3.49,
2.4725,
1.455,
0.4375,
3.2,
2.1825,
1.165,
0.145,
2.9075,
1.89,
0.8725,
3.635,
2.6175,
1.6,
0.5825,
3.345,
2.3275,
1.31,
0.2925,
3.055,
2.035,
1.0175 ],

And on the current master branch, this gets inserted as one value per SliceTiming entry using -json_import:

$ mrinfo -property SliceTiming dwi_raw.mif.gz
0
2.7625
1.745
0.7275
3.49
2.4725
1.455
...

Using the direct DICOM import all within MRtrix3, this ends up as a single comma-separated list of values in a single entry:

$ mrinfo -property SliceTiming dwi_raw.mif.gz
0,2.76250005,1.745,0.727500021,3.49000001,2.47250009,1.45500004,0.4375,3.20000005,2.18249989,1.16499996,0.144999996,2.90750003,1.88999999,0.872500002,3.63499999,2.61750007,1.60000002,0.582499981,3.34500003,2.3275001,1.30999994,0.292499989,3.05500007,2.03500009,1.01750004,0,2.76250005,1.745,0.727500021,3.49000001,2.47250009,1.45500004,0.4375,3.20000005,2.18249989,1.16499996,0.144999996,2.90750003,1.88999999,0.872500002,3.63499999,2.61750007,1.60000002,0.582499981,3.34500003,2.3275001,1.30999994,0.292499989,3.05500007,2.03500009,1.01750004

I guess #1735 and #1738 will definitely interact here, but I'm unsure about the details...

I suspect there's a number of gremlins arising from the fact that I hurriedly got the JSON handling working well enough to be able to produce and process data that looked like BIDS, but wasn't cross-checked for compatibility with other packages.

#1735 is a fairly gross deviation from what the data should have been, for which I put a hack into dwipreproc to compensate.

#1738 better demonstrates the fundamental issue: JSON supports multiple data types and hierarchical data, whereas we internally store any non-compulsory header data as a std::map<std::string, std::string>. We therefore need to carefully consider how that conversion should take place in both directions. #1738 does a decent amount of gymnastics to make this work for export in what I think is a sensible way. This issue shows that the import stage needs more careful consideration as well more generally.

In terms of this specific case, one might ask: Given these data contain one entry per volume, and other header entries containing one entry per volume (e.g. dw_scheme) have one header entry (/ row) per volume, should the same be done for SliceTiming, even if it's only a single scalar value per volume? I tend to think that collapsing such data into a single row makes sense (in #1735 I put a bunch of logic gymnastics in place in dwipreproc just in case the data come in in unexpected formats), but that's nevertheless an explicit decision. But the reason I made that first comment is that if you make these changes in order for JSON import of SliceTiming to work as intended, but comma-delimit the string data in the header, then upon JSON export, SliceTiming will come out as a list of lists of floats rather than a list of floats.

Ideally we should have a unit test that imports a pre-prepared JSON file (with as many nasties as we wish to support) to an empty header, exports it, then raw diffs the JSON contents.

Aborting; given magnitude of issues with JSON data handling, will not be resolving such on master, instead relying on imminent tag update that will include changes in #1843.