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

[Mathieu Malaterre]

Hi Florian,

On Mon, May 12, 2008 at 12:37 PM, Florian Pierron
<F.Pierron at exeter.ac.uk> wrote:
> 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

<rant>
switching to my win32 laptop to download a zip file
</rant>

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

Hum... Looks like it has been fixed in gdcm 1.3.x (aka CVS HEAD), but
never backported to gdcm 1.2 (which is the branch used by ITK). I'll
investigate some more. Thanks for report.

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

See gdcm::Util::GetVersion()

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

$ ./bin/gdcmdump /tmp/ITK-GDCM_NotProperlyLoading/BlackImage/I0000004
| grep Rescale
...
(0028,1052) DS [0 ]                                               #
2,1 Rescale Intercept
(0028,1053) DS [0 ]                                               #
2,1 Rescale Slope

See my previous rant on the dicom newsgroup:

http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/4327bb2fd789603d/f19a5e6a29858c36#f19a5e6a29858c36

Eventhough a slope of 0 is not forbidden by the standard it is changed
to 1.0 in gdcm 2.x. I need to backport the fix to gdcm 1.2.x, thanks
for report. But you should really contact your manufacturer, strictly
speaking the image should appear as black.


>  I have another question about GDCMSeriesFileNames. When calling SetDirectoy
> () it can take some time to compute.

Yup. GDCM 1.2.x has some design flaws and parsing is pretty slow. GDCM
2.x is a ground up rewrite of GDCM 1.x which solve this particular
issue (among other).

> Does this function only read the header

Correct.

> of the dicom file or does it have to read the whole file to get the
> information needed?

No it 'seekg' the Pixel Data element.

> Is it possible to get the progress events?

This is not implemented unfortunately. You can only get event at the
ITK level (after each file is read for example). Not sure if this is
implemented.

> 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

Yes and no :)

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

ITK & gdcm are ostream based, so you should not make any assumption on
the type of ostream you are dealing with.

> If so, multithreading won't help, or am
> I wrong?

multithreading *might* work for you. For instance we have now two
types of reader in GDCM: a threaded version and a non-threaded
version:

http://gdcm.sourceforge.net/html/classvtkGDCMThreadedImageReader.html

http://gdcm.sourceforge.net/html/classvtkGDCMImageReader.html

Unless you have access to a pretty decent RAID system + multicore
system, the threaded version only *really* works with some kind of
caching (such as readahead, or some POSIX equivalent call). See for
more info the gdcmreadahead daemon:

http://gdcm.svn.sourceforge.net/viewvc/gdcm/Sandbox/gdcmreadahead/

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

HTH

-- 
Mathieu