BIC-MNI / minc-tools

Basic minc-tools from former minc repository
Other
30 stars 25 forks source link

dcm2mnc devel HEAD cannot properly convert Bruker 7T timeseries data #36

Closed gdevenyi closed 8 years ago

gdevenyi commented 8 years ago

Currently puts timeseries on Z axis

Can provide a variety of sample data (structural and timeseries) via private link

gdevenyi commented 8 years ago

https://github.com/neurolabusc/dcm2niix properly converts data

rdvincent commented 8 years ago

sure, send the link...

andrewjanke commented 8 years ago

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

rdvincent commented 8 years ago

@andrewjanke Thanks for the information.

gdevenyi commented 8 years ago

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.

rdvincent commented 8 years ago

I'll take a look at it today (or possibly tomorrow) and see if I can figure out what's up with this.

rdvincent commented 8 years ago

@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.

gdevenyi commented 8 years ago

Hrm, that didn't change anything for the example files I sent you, I still get a big z-space with no timeseries.

rdvincent commented 8 years ago

@gdevenyi That's odd, I just tested with those three sequences and get 150 time points for the two dynamic sequences.

rdvincent commented 8 years ago

@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
gdevenyi commented 8 years ago

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)

gdevenyi commented 8 years ago

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.

rdvincent commented 8 years ago

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.

gdevenyi commented 8 years ago

Hi, just following up here re: the lumping series together problem. Any progress I can test?

rdvincent commented 8 years ago

@gdevenyi Try this now. Bruker should work. Still working on getting the Philips N-D data "right".

gdevenyi commented 8 years ago

Looks good now