Curious about differences in vtkMassProperties for VTK 5.04 and VTK 5.4.2
Question
I have a small python VTK
function that calculates the volume and surface area of an object embedded in a stack of TIFF
images. To read the TIFF's
into VTK
, I have used vtkTIFFReader
and processed the result using vtkImageThreshold
. I then use vtkMassProperties
to extract the volume and surface area of the object identified after thresholding.
With VTK-5.04
, this function returns the correct value for a test stack (3902 pixels). However, using VTK-5.4.2
the same function returns a different value (422 pixels). Can someone explain this?
Code
def testvtk():
# read 36 TIFF images. Each TIFF is 27x27 pixels
v16=vtk.vtkTIFFReader()
v16.SetFilePrefix("d:/test/slice")
v16.SetDataExtent(0,27,0,27,1,36)
v16.SetFilePattern("%s%04d.tif")
v16.SetDataSpacing (1,1,1)
v16.Update()
# Threshold level for seperating background/foreground pixels
maxthres=81
# Threshold the image stack
thres=vtk.vtkImageThreshold()
thres.SetInputConnection(v16.GetOutputPort())
thres.ThresholdByLower(0)
thres.ThresholdByUpper(maxthres)
# create ISO surface from thresholded images
iso=vtk.vtkImageMarchingCubes()
iso.SetInputConnection(thres.GetOutputPort())
# Have VTK calculate the Mass (volume) and surface area
Mass = vtk.vtkMassProperties()
Mass.SetInputConnection(iso.GetOutputPort())
Mass.Update()
# just print the results
print "Volume = ", Mass.GetVolume()
print "Surface = ", Mass.GetSurfaceArea()
Note
By testing both VTK-5.4.2 and VTK-5.2.1, I narrowed things down a bit and believe this behaviour was introduced between versions 5.0.4 and 5.2.1.
Update
It seems that in VTK-5.4.2, vtkTIFFReader ignores the x and y values set in the SetDataSpacing method. Instead vtkTIFFReader is calculating the x and y dataspacing from the resolution reported by the TIFF files.
Solution
I have never heard of VTK before, but here it goes.
Good thing about opensource software is that you can check the source code directly. Better yet, if there's web-based version control browser, we can talk about it online like this.
Let's see vtkMassProperties
in question. 5.0.4 uses r1.28 and 5.4.2 uses r1.30. Here's the diff between r1.28 and r.30. The part that may affect volume calculations are
vol[2] += (area * (double)u[2] * (double)zavg); // 5.0.4
vol[2] += (area * u[2] * zavg); // 5.4.2
and
kxyz[0] = (munc[0] + (wxyz/3.0) + ((wxy+wxz)/2.0)) /(double)(numCells); // 5.0.4
kxyz[0] = (munc[0] + (wxyz/3.0) + ((wxy+wxz)/2.0)) /numCells; // 5.4.2
but all changes look ok to me.
Next suspicious are the vtkMarchingCubes
. Diff between r1.1.6.1 and 1.5.
self->UpdateProgress ((double) k / ((double) dims[2] - 1)); // 5.0.4
self->UpdateProgress (k / static_cast<double>(dims[2] - 1)); // 5.4.2
and
estimatedSize = (int) pow ((double) (dims[0] * dims[1] * dims[2]), .75); // 5.0.4
estimatedSize = static_cast<int>(
pow(static_cast<double>(dims[0]*dims[1]*dims[2]),0.75)); // 5.4.2
Again, they are fixing stuff on casting, but it looks ok.
Might as well see vtkImageThreshold
too. Diff between r1.50 and r1.52.
lowerThreshold = (IT) inData->GetScalarTypeMin(); // 5.0.4
lowerThreshold = static_cast<IT>(inData->GetScalarTypeMin()); // 5.4.2
There are bunch more, but they are all casting stuff.
It gets more interesting with vtkTIFFReader
. Diff between 1.51 and 1.63. As you can see by the difference in the revision numbers, there has been some development in this class compared to others. Here are the checkin comments:
- ENH: Add an name for scalars. Visible in Paraview.
- ENH: vtkDataArray now has a new superclass-vtkAbstractArray...
- ENH: Set default number of sampels per pixel for files that are missing this meta data.
- ENH: Read only what you need.
- ENH: add multipage TIFF file support
- ENH: print ivars
- BUG: TIFF Reader did not properly account for RLE encoded data. Also, ExecuteInformation overwrote user specified spacing and origin.
- BUG: when reading beach.tif (from current CVS VTKData), the image would be loaded upside down.
- STYLE: s/OrientationTypeSpecifiedFlag/OriginSpecifiedFlag/g and s/OrientationTypeSpecifiedFlag/SpacingSpecifiedFlag/g
- BUG: Reader was not handling extents properly.
- COMP: Fixing a warning.
- COMP: Getting rid of a warning.
From the amount of changes that was made in vtkTIFFReader, I would guess that the difference in behavior is coming from there. For example, it may have started to recognize your Tiff as different format and changed the internal pixel values. Try printing out pixel values and see if there is any difference. If the pixel values have changed maxthres=81
may be too high.