Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
gdevenyi opened this issue May 13, 2016 · 16 comments
Closed
Assignees

Comments

@gdevenyi
Copy link

Currently puts timeseries on Z axis

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

@gdevenyi
Copy link
Author

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

@rdvincent
Copy link
Member

sure, send the link...

@rdvincent rdvincent self-assigned this May 13, 2016
@andrewjanke
Copy link
Member

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
#36 (comment)

@rdvincent
Copy link
Member

@andrewjanke Thanks for the information.

@gdevenyi
Copy link
Author

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
Copy link
Member

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

@rdvincent
Copy link
Member

@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
Copy link
Author

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

@rdvincent
Copy link
Member

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

@rdvincent
Copy link
Member

@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
Copy link
Author

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
Copy link
Author

gdevenyi commented Jun 6, 2016

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
Copy link
Member

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
Copy link
Author

gdevenyi commented Jul 5, 2016

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

rdvincent pushed a commit that referenced this issue Jul 6, 2016
@rdvincent
Copy link
Member

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

@gdevenyi
Copy link
Author

Looks good now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants