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