[Insight-users] Problem reading specific dicom files (bug?)

[Florian Pierron]

Dear ITK team,

I have some problems reading specific dicom files with ITK 3.4. The 
files were too big to be sent as an attachment, so they are available in 
a zip format through the following link:

http://workspace.office.live.com/?id=qACRhYjgzOTE5OC1mNWZkLTQ2ZDctYWE4Ny04YjdhOGFjNjk1ZGIAe6Ot2CwEEsZEkYzeYgi32vt9e2HUvUXvrmlGoLxAl4TOLEZ9ABhmLnBpZXJyb25Ac2ltcGxld2FyZS5jb20A

The zip file contains a screenshot of what is expected (using XMedCon 
and DicomWorks) and a screenshot of what I get with ITK 3.4. There is 2 
different series that can't be read. One of them (the one I called 
'ReadingByte') has been posted to the GDCM developers 3 years ago and I 
am pretty sure they fixed it already. So my question is more how do we 
know which version of GDCM is present in ITK 3.4. Is there a file I can 
read to get this information (or a function such as GetGDCMVersion). Is 
there a new version of GDCM in ITK 3.6? (if someone could try if the 
files are loaded successfully on the newest ITK version, that would be 
great). The second set, I get a completely black image.

I have another question about GDCMSeriesFileNames. When calling 
SetDirectoy () it can take some time to compute. Does this function only 
read the header of the dicom file or does it have to read the whole file 
to get the information needed? Is it possible to get the progress 
events? It doesn't seem to work for me so I was wondering if it was 
implemented. Last question, I was wondering if implementing a 
multi-threading version of this function will help and if so, a quick
guide line on how to do it (with itkMultithreader?) will be appreciated. 
Is the access to disk a serial process? If so, multithreading won't 
help, or am I wrong?

Finally, I would like to thank the ITK community for developing such a 
great library, thank you guys! (I don't say that to increase my chances 
of having an answer ;-) )

Regards,
Florian