[Mrtrix-discussion] mrconvert DICOM file order

Mon Jul 30 06:33:27 PDT 2012

Donald,

I discovered last week that PTK is a private toolkit :(.
Unfortunately, I can't give you more information about it.

I really don't know how the data have been acquired. Maybe the authors
of the challenge knows more about it. DICOM is a really strange
format...

Regards
-F

On Fri, Jul 27, 2012 at 12:55 AM, Donald Tournier
<d.tournier at brain.org.au> wrote:
> 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

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