Closed gdevenyi closed 8 years ago
https://github.com/neurolabusc/dcm2niix properly converts data
sure, send the link...
Be aware that on the Bruker platform it is up to the author of the pulse sequence to create the correct mapping from phase directions to real dimensions if they have modified the original phase encoding directions. Thus you can have the situation where the dimension order will appear to change dependant on the pulse sequence. This is only an issue with DICOM exported data from a Bruker scanner. The ParaVision directory will always have the correct mapping in the acqp file but it is in no way straight forward to decode this and not available in DICOM headers last I checked.
See pvconv from Matthew Brett for a Bruker converter that works directly on the paravision directories (and will output MINC files and NIFTI in the correct orientation -- it is based upon my old pv2mnc converter).
My suggestion is not to use Bruker DICOM export and convert from the Paravision format instead. It is likely that you will want to keep the paravision directory in case of any future reconstruction needs from the raw fid file.
On 14 May 2016 at 04:10, Gabriel A. Devenyi notifications@github.com wrote:
**radiological coordinates
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/BIC-MNI/minc-tools/issues/36#issuecomment-219146974
@andrewjanke Thanks for the information.
Thanks for the feedback @andrewjanke I wasn't aware of the issues with the DICOM converter. I'll go back and do some comparisons against pvconv.
In the meantime, @rdvincent all I can say is, dcm2niix did convert this successfully to a time serie, not sure if it's doing some unsafe heuristics in order to manage it.
I'll take a look at it today (or possibly tomorrow) and see if I can figure out what's up with this.
@gdevenyi So there is a fix checked into develop. The Bruker series do not indicate either the total number of slices or time points. We had historically taken a conservative view and treated all images as slices in the absence of this information. I added some code to actually calculate the number of distinct spatial coordinates, which gives us a minimum number of slices for a normal acquisition, and use this to compute the probable number of time points. These values are used only of the standard fields are missing, so it should be quite safe.
Hrm, that didn't change anything for the example files I sent you, I still get a big z-space with no timeseries.
@gdevenyi That's odd, I just tested with those three sequences and get 150 time points for the two dynamic sequences.
@gdevenyi I re-tested on a different machine with a different version of Ubuntu and got the same results:
rvincent@ace-ws-21:/data1/users/bert/images/dicom/gd_bruker/DICOM$ mincinfo mch_dev110_002_20160513_141126/*
file: mch_dev110_002_20160513_141126/mch_dev110_002_20160513_141126_1048577e1_mri.mnc
image: signed__ short -32768 to 32767
image dimensions: time zspace yspace xspace
dimension name length step start
-------------- ------ ---- -----
time 150 0 54954
zspace 24 0.75 -8.825
yspace 30 -0.3 4.7
xspace 64 -0.3 9.6
file: mch_dev110_002_20160513_141126/mch_dev110_002_20160513_141126_1179649e1_mri.mnc
image: signed__ short -32768 to 32767
image dimensions: time zspace yspace xspace
dimension name length step start
-------------- ------ ---- -----
time 150 0 57151
zspace 48 0.38 -9.13
yspace 24 -0.38 4.76
xspace 60 -0.38 11.4
file: mch_dev110_002_20160513_141126/mch_dev110_002_20160513_141126_131073_mri.mnc
image: signed__ short -32768 to 32767
image dimensions: yspace zspace xspace
dimension name length step start
-------------- ------ ---- -----
yspace 90 -0.1 4.6
zspace 180 -0.1 8.6
xspace 160 -0.1 7.4
This is probably another instance of "make install" not replacing all the things that needed replacing. I will purge and re-install and test again (we had the same issue when you added the adjustable register views)
Okay, I found the problem.
I have been running the conversion as:
> dcm2mnc */* .
Which is lumping all the series together, and breaking your heuristics. When I run it on an individual series at a time, I get your output.
Ahh, good to know. I'll investigate why that causes it to do the wrong thing. I think we should be able to handle this case as well.
Hi, just following up here re: the lumping series together problem. Any progress I can test?
@gdevenyi Try this now. Bruker should work. Still working on getting the Philips N-D data "right".
Looks good now
Currently puts timeseries on Z axis
Can provide a variety of sample data (structural and timeseries) via private link