Could not sort DICOM filenames. It could be that this is an invalid collection.

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Run ./dre devide
2.Add a directory with my dicom data
3.Press 'Scan'
4.Press 'IPP Sort' 

What is the expected output? What do you see instead?
Expected: everything to be OK.
Result: I get error message: "Could not sort DICOM filenames. It could be that 
this is an invalid collection."

What version of the product are you using? On what operating system?
v9.8.3784, Kubuntu 11.10 
DICOM data was acquired from GE Sсanner 1.5 Tesla

Please provide any additional information below.
I don't really care about this particular message but it seems to me that the 
problem behind it causes troubles with executing simple networks like 
DICOMReader-->slice3dVWR.

So the question is why my collection could be invalid? Is it my problem and I 
can fix it somehow or is it DeVIDE's issue. Despite the issue I can view my 
images.

Original issue reported on code.google.com by [email protected] on 19 Jan 2012 at 7:44

[GoogleCodeExporter]

Is anyone actually interested in this bug report?

Original comment by [email protected] on 16 Feb 2012 at 2:24

[GoogleCodeExporter]

Of course, but you have to give us a little time to respond, it's a 
for-the-love-of-the-matter effort.

When you get that error, it means that the the IPP (image position patient) in 
your DICOM slices doesn't sort correctly. The best you can do is to check out 
the series in the DICOMBrowser and then see if you can spot any 
inconsistencies. What often works, is then selecting the subset that *does* 
form a valid stack, and dragging-dropping that onto the canvas.

Please let me know how that went.

Original comment by cpbotha on 17 Feb 2012 at 9:49

[GoogleCodeExporter]

(in short: there is something going on with your series. sometimes the first 
overview image is the culprit.)

Original comment by cpbotha on 17 Feb 2012 at 9:51

[GoogleCodeExporter]

Good to know that. I fully understand your "for the love of the matter" 
attitude, because I was a software developer myself. It's cool that you enjoy 
it! I was just curios if you guys have even seen the issue ;) Hope you'll 
understand me as well. As this issue doesn't really cause me any particular 
trouble because I was just playing with the software. My intentions are to help 
make devide a better software. 

As for the issue. I do understand that devide can't sort it, I just don't 
understand why. I mean what parameter of the images' metadata devide uses for 
sorting. If you can tell me (don't really want to dig the source code myself, 
sorry I am a bit lazy and out of time ;) I would be able to look carefully into 
metadata and see what is wrong. 

Anyway I'll try what you've suggested and let you know.

Original comment by [email protected] on 18 Feb 2012 at 7:54

[GoogleCodeExporter]

Hi there!

DeVIDE tries to stack the images according to the Image Position Patient (IPP) 
as well as the Image Orientation Patient (IOP) vector, as recommended by DICOM 
gurus everywhere. If the spacing is not consistent, then it gives that error 
message.

Original comment by cpbotha on 21 Feb 2012 at 12:12

[GoogleCodeExporter]

It's been a while, sorry guys!

Anyway, the only two things that are changing in metadata of the images (in one 
series) are DataOrigin key and ImageNumber. So I am not sure where to look for 
IPP and IOP in order to check them? I am totally new to this stuff so I beg you 
pardon if I ask some very simple questions. I guess these vectors are stored in 
some more high-level places, like overall metadata or something... Please help 
me with this! 

Original comment by [email protected] on 9 Apr 2012 at 10:08

[GoogleCodeExporter]

The IPP ond IOP are stored in the normal DICOM tags. It's possible that the 
DICOMBrowser doesn't show them in the metadata window due to limitations in the 
VTK interface, I'm not sure.

Next thing I would do is to try loading a subset of the data (3 slices in the 
middle somewhere), and also to load the data in some other software (IrfanView 
with DICOM plugin) to see if the data is OK.

Original comment by cpbotha on 13 Apr 2012 at 3:35

[GoogleCodeExporter]

Hello all,

I found devide today, when trying to figure out why InVesalius 3.0 beta 3 is 
not running on my machine.  Both the 32/64 bit builds of InVesalius just 
silently exit on my machine.  To the source, and realized I needed a 2.7.3 
python vtk module which I didn't want to build...googling til devide.  I got 
distracted, and I've been playing with devide since...

I am experiencing a similar "Could not sort DICOM filenames" error, mine says 
"before loading", not "It could be that this is an invalid collection." as 
yours stated.

14:55:45: Traceback (most recent call last): 
14:55:45:   File "C:\Program Files\DeVIDE-RE\devide\module_manager.py", line 
879, in execute_network     self._module_dict.values()) 
14:55:45:   File "C:\Program Files\DeVIDE-RE\devide\network_manager.py", line 
46, in execute_network     self._devide_app.scheduler.execute_modules(sms) 
14:55:45:   File "C:\Program Files\DeVIDE-RE\devide\scheduler.py", line 698, in 
execute_modules     self.get_scheduler().execute_modules(scheduler_modules) 
14:55:45:   File "C:\Program Files\DeVIDE-RE\devide\scheduler.py", line 569, in 
execute_modules     mm.execute_module(sm.meta_module, sm.part) 
14:55:45:   File "C:\Program Files\DeVIDE-RE\devide\module_manager.py", line 
848, in execute_module     meta_module.execute_module(part, streaming) 
14:55:45:   File "C:\Program Files\DeVIDE-RE\devide\meta_module.py", line 358, 
in execute_module     self.instance.execute_module() 
14:55:45:   File "C:\Program 
Files\DeVIDE-RE\devide\modules\readers\DICOMReader.py", line 163, in 
execute_module     'Could not sort DICOM filenames before loading.') 
14:55:45: ModuleManagerException: Unable to execute part 0 of module dvm0 
(DICOMReader): Could not sort DICOM filenames before loading. 
14:55:45: Unable to execute part 0 of module dvm0 (DICOMReader): Could not sort 
DICOM filenames before loading.

I have tried using windows explorer to select all of the dcm files and drag 
them into DeVIDE, which did work, but looking at the config on DICOMReader the 
files were not sorted properly.  I tried "remove files" and added them all back 
in using "add files".  They look all there and in proper order...

The data is corrected data that came out of a gdcm script I modified to correct 
the phase-wrap artifacts...apparently it is not correct yet...
The DICOM files I'm using to test can be found here:
http://dl.dropbox.com/u/5668823/visibledave/visibledave-SAGITTAL_wrapped_spaced.
7z = a 7zip archive of dcm files weighing in at 5.5mb

More information about me and the data can be found here:
http://dave.thehorners.com/tech-talk/projects-research/visible-dave-project

Very nice work, I'm happy to find this project!
--dave

Original comment by [email protected] on 21 Oct 2012 at 8:09

[GoogleCodeExporter]

Dear Dave,

Thanks for stopping by! The DICOMReader sorts all DICOM slices according to 
their Imahge Position Patient (IPP) metadata, that is, their actual relative 
location in 3D scanner space. If you're seeing that sorting error, it mostly 
means that the IPPs of all the files in the DICOMReader don't check out.

Could you do it via the DICOMBrowser? You just give the DICOMBrowser the 
directory containing all of your DICOM filenames, and it'll take care of 
sorting them all into studies and series. You can drag and drop a complete 
series onto the DeVIDE canvas. See http://youtu.be/iLfu6JXkWP4 for a demo, and 
let me know how it goes!

Original comment by cpbotha on 21 Oct 2012 at 8:13

[GoogleCodeExporter]

Charl,
Thanks for the quick response.  Yes, I guess I meant to say that I had used the 
DICOMBrowser, and it loads all the slices fine, but the ordering is 
incorrect....

And actually, each slice is being seen as a separate study....i forgot about 
that issue with the data coming out of the gdcm gdcmimg app that I modified to 
support phase wrapping.  I think I wrote a message to the gdcm people at one 
point, but looking now I can't find the message on the list.

Sounds like I need figure out which DICOM manipulations are needed to get all 
these modified dcm files to be seen as one single series, or figure out a 
better place to perform/implement the phase-wrap adjustment (like within 
DeVIDE) on the original datasets...

All my issue and not something wrong with DeVIDE...

Thanks again Charl,
--dave

Original comment by [email protected] on 21 Oct 2012 at 9:28

[GoogleCodeExporter]

Hey. I've run into this problem as well. As did another person who is using 
DeVIDE. In our case (I believe that) this specifically happens with MRI images 
when the IPP orientation is exactly 90 degrees relative to axial. In this case 
GDCM itself fails. Note that the BSD open-source project MITK also relies on 
VTK and ITK but have implemented their own custom reader that does not suffer 
the same problem. 

Why this happens is still not exactly clear to me. I was planning to implement 
a new reader that re-uses code from MITK but haven't gotten around to it yet. 
You're (the coders among you) are also welcome to give it a go.

Original comment by [email protected] on 7 Dec 2012 at 12:19

• Added labels: Type-Defect, Priority-High, OpSys-All, Component-Persistence

[GoogleCodeExporter]

Could you test with 3 adjacent images from the middle of your set? I'm not 
entirely convinced by your hypothesis yet. :-) 

We could also send such a subset to the author of gdcm: In the past be has been 
extremely helpful given such re producers. 

Original comment by cpbotha on 7 Dec 2012 at 12:30

[GoogleCodeExporter]

Okay I tested, and it even fails with only two subsequent slices. The suspicion 
is that this happens because the affected slices don't have 
ImagePositionPatient data, but this hasn't been confirmed yet. Unfortunately I 
can't upload the example due to the fact that it contains patient-specific 
data, and that I don't have a tool for anonymizing it.

Although not all slices in the set are affected. I could find a set that didn't 
load, and then could find subsets for which loading work, while some other 
subsets failed.

Enabling the DICOMReader's _config.robust_spacing (via introspection) seems to 
be a crude fix for the problem, but this doesn't really solve the issue to my 
satisfaction.

Original comment by [email protected] on 12 Dec 2012 at 3:19

[GoogleCodeExporter]

For the record, the orientation in this case was not directly 90 degrees 
relative to axial (although close to it), so my former hypothesis is indeed 
incorrect.

Original comment by [email protected] on 12 Dec 2012 at 3:20

[GoogleCodeExporter]

Just found a reproducable example in which the IPP field is present in all 
slices, but where IPP sorting fails in the DICOMReader. Resorting to 'Sort by 
name' works in this case. 
The problem occurs even for 2 slices from the affected set, therefore 
consistent spacing isn't the issue (unique spacing since there are only 2 
slices).

See attached (anonymized) slices.

Original comment by [email protected] on 16 Dec 2012 at 6:30

Attachments:

• DeVIDE_IPP_Sort_Error.7z

[GoogleCodeExporter]

Just wondering if this issue was ever solved - I'm getting the same "could not 
sort dicom files before loading" error.

Original comment by [email protected] on 24 Jul 2014 at 10:40

[GoogleCodeExporter]

In most cases, it means there's an issue with the data you're trying to load.

Try some of the loading options in the DICOMReader to see if that helps with 
your problem, and let us know!

Original comment by cpbotha on 29 Jul 2014 at 9:06

[GoogleCodeExporter]

Hi there!
I see there has been a discussion going on about the problem that I also seem 
to have.

While loading a DICOM set I get a message saying: "DICOM IPP sorting yielded 
incorrect results".
Following the recommendations above through the DICOMBrowser I found out that I 
am missing 4 DICOM files in the stack at some places. Therefore, I can load 5 
separate (quite large) stacks of DICOM data and work around with them 
separately. But trying to get all the DICOMs together does not work. (I 
actually need a whole femur).
Is there a way to "rename" the IPP in DICOM files? So that I can work with a 
large DICOM set regardless of the lost files? (Sorry if the question sounds 
stupid - I'm not a programmer). 

Original comment by [email protected] on 25 Aug 2014 at 2:35