I am working with a diffusion MRI dataset acquired with Siemens’ Suppress 16-bit DICOM option inadvertently enabled during protocol setup. As I understand it, this results in 12-bit rather than 16-bit DICOM output. The acquisition includes b = 0, 1500 and 3000, with ~200 directions and AP–PA phase encoding, broadly similar to HCP data.
Could the reduced precision meaningfully affect FOD estimation, FD or SIFT2 weights? Could this introduce meaningful bias or additional noise in individual-differences analyses? I guess more importantly, would you recommend continuing data collection with 12-bit output for consistency, or switching to 16-bit and assessing comparability once the data collection is finalized?
I did not experience it myself, so I am not sure, but I would say it does not matter too much.
The only think you need to check is the maximum value is not reach, otherwise you may get negative value. This may happen in B=0 images only (since they have the highest signal) in CSF region. Have a look to check if you see bright to dark transition in the CSF
or just check the max value in your B0 images, if it is inferior to the max value one can code on 12bit, then you may are fine
since this will happen in csf region only, it may not be a big issue … (the fix is just to transform negativ value to the max value, as if you had a clip)
I’m not familiar with this Suppress DICOM output - I’ve never heard of it. But in general, DICOM data are very often recorded as 12-bit integers even though they are stored as 16-bit integers. To illustrate, here is what is recorded in the DICOM headers for some data acquired on our Siemens Terra.X fairly recently (for an mp2rage sequence, but this is fairly typical):
$ dcminfo -a long_filename.dcm
…
[DCM] 0028 0100 US 2 112322 BitsAllocated 16
[DCM] 0028 0101 US 2 112332 BitsStored 12
[DCM] 0028 0102 US 2 112342 HighBit 11
…
You can see that the information is stored using 16 bit integers, and yet they only store 12 bits.
In short, I wouldn’t worry about losing precision by going to 12 bits, I think that’s actually the default anyway (and has been for a very long time). You can usually verify this by looking at the maximum intensity in the image: it’ll typically be lower than 4095 (the maximum 12-bit integer) – though not always since there may be additional scale factors applied to the images when displaying the data (see the RescaleIntercept and RescaleSlope DICOM fields).
What I’m wondering though, is whether the Suppress option is really about saving a bit a space by packing these 12 bits that are recorded into 12 actual bits in the file. In other words, storing 4×12 bits into the equivalent of 3×16 bits (48 bits total). If that’s what is meant by that option, there’s a very good chance MRtrix won’t be able to handle these data… I strongly recommend you try having a look at the data to check (if you haven’t already). If that is an issue, there’s a good chance that dcm2niix will handle it correctly.