AFNI version info (afni -ver): Precompiled binary linux_ubuntu_16_64: Oct 26 2024 (Version AFNI_24.3.05 'Elagabalus')
Hi,
I am trying to open a child topic from afni-realtime-siemens-sms-epi-error. The goal is the same but the techniques are different. I convert the 16-bit enhanced DICOMs into NIFTI first and I use dcm2niix_afni -1 -s y -z 3 -b n in order to convert each 3D DICOM (enhanced so it is actually 4D but still in 3D for fMRI, so one file per volume). Then I use Dimon with the -file_type AFNI option. It works well for the Siemens vendor sequence where the values are coded in 16 bit but are actually with values 12 bits. But for the CMRR sequence, the data is actually written in 16 bits with e.g. max value 48737.
For both the vendor and the CMRR sequence, Dimon gives me the following warning:
scanning for first volume
** AFNI converts NIFTI_datatype=512 (UINT16) in file /home/jonathan/projects/rtfmri/converted/20241120.sub01.2024.11.20_11_21_17_STD_1.3.12.2.1107.5.99.3/sub01_6_1_1.nii to FLOAT32
For the vendor sequence, the values are below 4095 so it works. But for the CMRR, the values are higher and I get the kind of images I join as attachment. Is there any way with to feed the rt stream with 16 bit Nifti into Dimon? I have also tried to look for options in dcm2niix in order to downscale the data to 12 bit but it is not looking good so far. If it was only for RT-fMRI experiments then I would use vendor or switch off the case "16 bits DICOM" in the CMRR sequence, but it is rather to monitor motion in all fMRI runs on the scanner.
There seems to be a complete misreading of the data here. Explore whether byte swapping is needed in the to3d interface or command line(3Ds format, -2swap or -4swap options). Based on your previous thread, it looks like we expect to see values around 2300, and not ranging from -32767 to 48737.
I have tried to3d (so not Dimon) with -2swap, -4swap but it does not seem that to3d accepts Nifti as input.
Since I have Nifti as real-time input, I need to use Dimon with -file_type AFNI as option.
With Dimon, I could use "rev_byte_order" option, but the result was similar.
I can open the same Nifti file with AFNI and it is displayed correctly as a brain.
It is when I send them through Dimon that i get the erroneous pictures.
In order to summarize:
If I run Siemens sequence or CMRR's sequence (but with option "stop 16 bit DICOM"), then I can get the real-time afni to work by first converting enhanced DICOMS into NIFTI with dcm2niix and then using these NIFTI as input for Dimon.
But, if I choose to run CMRR with 16 bit DICOMS, then the same technique provides the erroneous pictures I have sent earlier. However, I can open the same NIFTI directly with AFNI (i.e. not through Dimon).
I think that for the moment I skip the real-time monitoring of motion for CMRR, or I'll run the CMRR sequence in 12-bits mode. Thanks anyway!
It looks like you have good work-arounds. I found this information from the CMRR documentation:
Suppress 16-bit DICOM: This option will revert the image output to the traditional standard 12-bit DICOM format. This may be needed for compatibility with some postprocessing software. Note that dynamic range is limited with this option, and care will need to be taken to adjust the FFT scale factor to ensure clipping does not occur.
Yes. I will ask CMRR's forum if there is any downside of switching to 12-bits. The DICOMS are still enhanced though (among other things information about each slice within the header) but that is worked around by first converting to Nifti.
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.
