[vtkusers] DICOM image rendered incorrectly

[David Gobbi]

Hi Eric,

Usually when I see an artifact like this, my first suspicion is that it is
one of those
rare images with "12 bits allocated".   But the metadata clearly says 16
bits, so I
can't say exactly what is different about your image.  If you email it to
me, then
I can take a closer look.

Please not that the metadata in the "Stamp Image Sequence" is irrelevant
here.
It only applies to the thumbnailed preview image, not to the main image.

The vtkDICOMImageReader that comes with VTK is very basic and it fails for
many
DICOM files.  Here are two other options:

1) The vtkGDCMImageReader that comes with GDCM

2) The vtkDICOMReader that comes with my vtk-dicom package,
at http://github.com/dgobbi/vtk-dicom/

  David


On Thu, Jan 9, 2014 at 4:29 PM, Fahlgren, Eric <
eric.fahlgren at smith-nephew.com> wrote:

>  O learned denizens of VTK land,
>
>
>
> I have been presented with a wacky DICOM image, which fails to render
> properly in vtk (looks like banded noise instead of a shin bone).  I have
> produced a gdcmdump of the file, which uncovers what appears to me to be a
> conflict in the pixel format.  Here are what I believe to be the salient
> parts of the dump, note that in the main metadata the pixels are claimed to
> be 10-bit in 16-bit allocation, but in the image data metadata, it is shown
> to be 8-bit pixels in 8-bit boxes.
>
>
>
> (0028,0100) US 16                                                 # 2,1
> Bits Allocated
>
> (0028,0101) US 10                                                 # 2,1
> Bits Stored
>
> (0028,0102) US 9                                                  # 2,1
> High Bit
>
> …
>
> (0089,1010) SQ (Sequence with undefined length)                   # u/l,1
> Stamp Image Sequence
>
>   (fffe,e000) na (Item with undefined length)
>
> …
>
>     (0028,0100) US 8                                              # 2,1
> Bits Allocated
>
>     (0028,0101) US 8                                              # 2,1
> Bits Stored
>
>     (0028,0102) US 7                                              # 2,1
> High Bit
>
>
>
> Now ImageMagick identify and convert appear to have no problems whatsoever
> with the file, in fact if I use convert to spit out a jpg/png/whatever,
> that renders properly.  I’ve included a single image, which contains small
> snapshots of the DICOM on the left and the ImageMagick-extracted png on the
> right.  (I have tried to use gdcmconv and raw to reformat the file, but
> have failed thus far to get any effect.)
>
>
>
>
>
> Here’s the code that produces the DICOM rendering.
>
>
>
> #!/usr/bin/env python
>
> import vtk
>
>
>
> reader = vtk.vtkDICOMImageReader()
>
> reader.SetFileName("IM3")
>
> ia = vtk.vtkImageActor()
>
> ia.GetMapper().SetInputConnection(reader.GetOutputPort())
>
>
>
> ren = vtk.vtkRenderer()
>
> renWin = vtk.vtkRenderWindow()
>
> renWin.AddRenderer(ren)
>
> iren = vtk.vtkRenderWindowInteractor()
>
> iren.SetRenderWindow(renWin)
>
> iren.Initialize()
>
> ren.AddActor(ia)
>
> ren.SetBackground(1.0, 1.0, 1.0)
>
> renWin.SetSize(400, 800)
>
> renWin.Render()
>
> iren.Start()
>
>
>
> What I suspect is happening, is that the VTK DICOM reader is using the
> numbers from the main metadata to interpret the pixel data, thus resulting
> in bit shifts that cause the banding in the image.
>
>
>
> Has anyone seen this sort of problem before?  Even better, if you have
> seen it, how did you cure it?  (I’ve anonymized the x-ray headers, so if
> anyone would like a copy of the offending image file, it’s ok to
> distribute.)
>
>
>
> Thanks in advance,
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140109/aaedf914/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 169536 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140109/aaedf914/attachment-0001.png>