[Mrtrix-discussion] mrconvert DICOM file order

Donald Tournier d.tournier at brain.org.au
Thu Jul 26 21:55:36 PDT 2012


Hi Felix,

I guess adding an option to sort by instance number is a possibility. Could
you give me some more information about this PTK tool you mentioned? I
can't seem to find it on the web...

I'm also interested in how these data were acquired. I've been working
primarily from Siemens data for the last decade or so, and I've never
encountered this problem. I'm guessing these data would have been acquired
using a custom sequence, not the Siemens product sequence? I've also not
had any problems loading data acquired using the MGH WIP diffusion
sequence, so I'd be interested to know what the cause of the problem was...

Cheers,

Donald.


On 27 July 2012 06:27, Félix C. Morency <felix.morency at gmail.com> wrote:

> Donald,
>
> Thank you for your precise answer. It might be a good idea (?) to add
> an option allowing the user to choose by which DICOM tag to perform
> the sorting. A last resort could be to sort according to the file
> name. The software would be robust even in the case of malformed
> ordering.
>
> Also, the PTK demosaicing tool is handling the Pittsburgh dataset
> correctly.
>
> Thanks,
> -F
>
> On Tue, Jul 24, 2012 at 8:23 PM, Donald Tournier
> <d.tournier at brain.org.au> wrote:
> > Hi Felix,
> >
> > OK, it looks like the AcquisitionNumber fields are the problem. MRtrix
> will
> > use this number to sort DICOM images, ahead of anything else. The actual
> > sorting is done according to the code at lib/file/dicom/image.cpp:190,
> and
> > basically does:
> > - sort by acquisition number; if identical:
> > - sort by distance along normal to slice; if identical:
> > - sort by sequence number; if identical:
> > - sort by instance number
> >
> > For what you sent, it looks like instance number would be more
> appropriate
> > in this case. What I don't understand is why the acquisition numbers
> appear
> > so random. Maybe I've hit the limits of my knowledge of DICOM... If
> anyone
> > can shed some light on the correct way to handle this situation, I'd
> love to
> > hear from them.
> >
> > In the meantime, you could simply delete line 190 of
> > lib/file/dicom/image.cpp, which presumably will then sort these data
> > correctly. The other way that wouldn't require modifying the code would
> be
> > to place each DICOM mosaic file in its own folder so that you can get
> MRtrix
> > to scan that image on its own, mrconvert each volume to a suitable name
> like
> > tmp-0001.nii, tmp-0002.nii, etc, and then do a final:
> > $ mrconvert tmp-[].nii combined.nii
> > Using the square brackets as above allows you to treat a numbered series
> of
> > 3D volumes as a 4D image (see the documentation for details). This
> approach
> > is a bit of a kludge, but could be scripted fairly easily.
> >
> > I was pretty sure my way of handling image sorting was robust (this is
> the
> > first reported issue of this kind since release in 2008!), but obviously
> > I'll need to take a closer look into this when I have a minute. If anyone
> > has a good source of information on this, I'm all ears!
> >
> > Cheers,
> >
> > Donald.
> >
> >
> > On 25 July 2012 00:13, Félix C. Morency <felix.morency at gmail.com> wrote:
> >>
> >> Donald,
> >>
> >> Thank you for the fast answer. Here are partial informations of
> >> 000[1-4].dcm using read_dicom:
> >>
> >> 0001.dcm
> >> [DCM] 20 10 SH 2 2588 StudyID : [ 1 ]
> >> [DCM] 20 11 IS 2 2598 SeriesNumber : [ 4 ]
> >> [DCM] 20 12 IS 2 2608 AcquisitionNumber : [ 1 ]
> >> [DCM] 20 13 IS 2 2618 InstanceNumber : [ 1 ]
> >>
> >> 0002.dcm
> >> [DCM] 20 10 SH 2 2694 StudyID : [ 1 ]
> >> [DCM] 20 11 IS 2 2704 SeriesNumber : [ 4 ]
> >> [DCM] 20 12 IS 4 2714 AcquisitionNumber : [ 256 ]
> >> [DCM] 20 13 IS 2 2726 InstanceNumber : [ 2 ]
> >>
> >> 0003.dcm
> >> [DCM] 20 10 SH 2 2694 StudyID : [ 1 ]
> >> [DCM] 20 11 IS 2 2704 SeriesNumber : [ 4 ]
> >> [DCM] 20 12 IS 4 2714 AcquisitionNumber : [ 258 ]
> >> [DCM] 20 13 IS 2 2726 InstanceNumber : [ 3 ]
> >>
> >> 0004.dcm
> >> [DCM] 20 10 SH 2 2690 StudyID : [ 1 ]
> >> [DCM] 20 11 IS 2 2700 SeriesNumber : [ 4 ]
> >> [DCM] 20 12 IS 2 2710 AcquisitionNumber : [ 3 ]
> >> [DCM] 20 13 IS 2 2720 InstanceNumber : [ 4 ]
> >>
> >> The data is public domain (Pittsburgh brain competition 2009 [1]). I
> >> can upload the data somewhere if you like.
> >>
> >> [1]: http://pbc.lrdc.pitt.edu/?q=2009b-download
> >>
> >> -F
> >>
> >> On Mon, Jul 23, 2012 at 7:32 PM, Donald Tournier
> >> <d.tournier at brain.org.au> wrote:
> >> > Hi Félix,
> >> >
> >> > I agree that doesn't sound too good. I don't understand how this could
> >> > happen, unless the series numbers stored in the DICOM header for each
> >> > file
> >> > are also in the wrong order - this is what MRtrix uses to order the
> >> > volumes.
> >> > My first guess would be that this is the problem. You can easily check
> >> > by
> >> > running read_dicom on each file to see what series number it reports,
> >> > and
> >> > whether they match the order you expected. If not, I'd need to take a
> >> > look
> >> > at the data - any chance you could send me these files?
> >> >
> >> > Cheers,
> >> >
> >> > Donald.
> >> >
> >> >
> >> > On 24 July 2012 03:57, Félix C. Morency <felix.morency at gmail.com>
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I am trying to create a 4D Nifti volume from multiple Siemens DICOM
> >> >> mosaic. The XYZ axis seem to be fine. However, slices along the time
> >> >> axis are presented in random (?) order.
> >> >>
> >> >> I reproduced the issue with four original DICOM mosaic: 000[1-4].dcm.
> >> >> I convert them to 4D Nifti using mrconvert. The resulting time axis
> is
> >> >> ordered as following: 0001, 0004, 0002, 0003, which is not the
> >> >> expected behaviour.
> >> >>
> >> >> Do you have any idea what's going on?
> >> >>
> >> >> Regards,
> >> >> --
> >> >> Félix C. Morency, M.Sc.
> >> >> Plateforme d’analyse et de visualisation d’images
> >> >> Centre Hospitalier Universitaire de Sherbrooke
> >> >> Centre de recherche clinique Étienne-Le Bel
> >> >> Local Z5-3031 | 819.346.1110 ext 16634
> >> >> _______________________________________________
> >> >> Mrtrix-discussion mailing list
> >> >> Mrtrix-discussion at www.nitrc.org
> >> >> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Jacques-Donald Tournier (PhD)
> >> > Brain Research Institute, Melbourne, Australia
> >> > Tel: +61 (0)3 9035 7033
> >>
> >>
> >>
> >> --
> >> --
> >> Félix C. Morency, M.Sc.
> >> Plateforme d’analyse et de visualisation d’images
> >> Centre Hospitalier Universitaire de Sherbrooke
> >> Centre de recherche clinique Étienne-Le Bel
> >> Local Z5-3031 | 819.346.1110 ext 16634
> >
> >
> >
> >
> > --
> > Jacques-Donald Tournier (PhD)
> > Brain Research Institute, Melbourne, Australia
> > Tel: +61 (0)3 9035 7033
>
>
>
> --
> --
> Félix C. Morency, M.Sc.
> Plateforme d’analyse et de visualisation d’images
> Centre Hospitalier Universitaire de Sherbrooke
> Centre de recherche clinique Étienne-Le Bel
> Local Z5-3031 | 819.346.1110 ext 16634
>



-- 
Jacques-Donald Tournier (PhD)
Brain Research Institute, Melbourne, Australia
Tel: +61 (0)3 9035 7033
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20120727/dff693c4/attachment-0001.html


More information about the Mrtrix-discussion mailing list