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

[Mathieu Malaterre]

On Tue, May 13, 2008 at 2:59 PM, Mathieu Malaterre
<mathieu.malaterre at gmail.com> wrote:
> 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.

while we are at it. A couple of notes:

1. Your files are invalid, they are a mixture of implicit/explicit
(dcmtk for instance cannot read them).

2. sin/cos are function that return value from -1 to 1.:

(0020,0037) DS [
5.000000\1.000000\0.000000\0.000000\0.000000\1.000000] #  54, 6
ImageOrientationPatient

I have absolutely no clue what ITK is doing with such cosine direction...

3. You cannot have empty components in your UID:

(0008,0018) UI [1.2.840.311572.4.1..9412.2.4]           #  28, 1 SOPInstanceUID

Your file will get rejected if send to a PACS system.

4. You cannot set the VR of Pixel Data to be OB when the Pixel is 16
bits (should be OW).


-- 
Mathieu