[vtkusers] A bug report: Changing input scalar type not handled correctly in some of the image filters

[Hämäläinen Janne]

Hi all,

We've found a very annoying behavior in some of the VTK's image filters. We
have implemented an image processing software that uses VTK for visualizing
image processing done with ITK. At some stage, we cast the scalar values of
the processed image from one type to another and present the new images
using VTK's visualization pipeline. This bug was found when
vtkImageChangeInformation filter was inserted in the pipeline and the input
scalar type was changed. The scalar type of the output is not updated
correctly in this filter and in a special group of filters. The group of
filters where this bug has been produced don't execute the input data, but
just change its information content. These include, for example,
vtkImageChangeInformation, vtkExtractVOI, vtkImageTranslateExtent, and
vtkImageClip. 

The bug is demonstrated in the attached source code. Please, find also
attached the image used by this small program. The program renders the input
image first using "short"-values. The image is then cast to "float" causing
a mixed up image. Next a resampler is added before the vtkImageClip that is
presumably causing the problem. This makes the pipeline update and image to
reappear correct. Last step is to cast the image back from "float" to
"short", which should cause a segmentation fault. This demo program produces
the bug using only VTK's pipeline, making it apparent that the problem is
not, for example, in the connection between VTK and ITK. We're using a
recent nightly version of VTK.

Actually, we think we've traced the source of the problem. I will try to
shortly describe what we've seen to happen (the demo program makes it easier
to understand what I'm talking about, see also the comments in the source
file). In vtkImageToImageFilter, ExecuteInformation method is used to set
the scalar type of the output, but this seems inappropriate (please correct
me if I'm not right). The reason is that ExecuteInformation is called at the
beginning of the pipeline execution, i.e. when the input is not yet updated
(ExecuteData is not called), and getting the scalar type of the input
returns the scalar type that is based on the previous execution. In
vtkImageToImageFilter, ExecuteData method explicitly allocates the output
data, which we think makes the output type current. In the problematic
filters, however, ExecuteData of vtkImageToImageFilter is overriden. This
causes them to use the scalartype that was got during ExecuteInformation
call making it incorrect if the input scalar type is changed. The scalar
type becomes correct the next time the pipeline is updated before the
problematic filter.

The solution that we found to solve the problem, was to add the following
line to the overriding ExecuteData()-method of the problematic filters:

outData->SetScalarType( inData->GetScalarType() );

Now the output data type is got from the current filter execution process,
not from the previous. This seems to behave correctly when changing between
any scalar types. Other option could be to make changes to the superclass,
but maybe someone wiser can decide on that. We're looking forward to hearing
comments on this,

-Janne


--
Janne Hämäläinen
Research Assistant
Helsinki University Central Hospital
Image Processing Centre

janne.hamalainen at hus.fi



 <<bugtestimage.jpg>>  <<changescalartypebugdemo.cxx>> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugtestimage.jpg
Type: image/jpeg
Size: 18289 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20031027/c7712066/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: changescalartypebugdemo.cxx
Type: application/octet-stream
Size: 2706 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20031027/c7712066/attachment.obj>