[vtk-developers] Removal of vtkImageToStructuredPoints.

[Charles Law]

In VTK 3.2, any filter that took vtkStructuredPoints would automatically 
create and insert a vtkImageToStructuredPoints filter into the pipeline if 
the input was set to an image.  This behavior worked most of the time but 
was fragile and caused many bugs/unexpected problems.  In our latest 
efforts to merge graphics and imaging, simplify the pipeline update 
mechanism and simplify writing imaging filters,  we were able to get rid of 
this automatic creation of a vtkImageToStructuredPoints filters.

Here is a list of the problems caused/uncovered by these changes and what 
had to be done to fix them.  I hope that this list will make it easier for 
you to get your filters working again (if they were broken by the 
change).  If you have any problems that you cannot solve, feel free to 
email me and we can discuss how the filters can be fixed.




1:  You can no longer connect up an imaging source to your filter if your 
filter takes vtkStructuredPoints as input.  This may not be a permanent 
problem because in the future vtkStructuredPoints could be typedefed to be 
equivalent the vtkImageData.

For now, the fix is to change the input from vtkStructuredPoints to 
vtkImageData.  This should work  (Not counting the problems listed below) 
because vtkStructuredPoints is an empty subclass of vtkImageData.



2: If you have a method EnlargeOutputUpdateExtent in your image filter, you 
should remove it and write an execute method.  Here is an example:

void vtkYourImageFilter::EnlargeOutputUpdateExtents(vtkDataObject *output)
{
	output->SetUpdateExtent(output->GetWholeExtent());
}

would be replaced by:

void vtkYourImageFilter::Execute()
{
	vtkImageData *outData = this->GetOutput();

	outData->SetExtent(outData->GetWholeExtent());
	outData->AllocateScalars();

	this->Execute(this->GetInput(), outData);
}



3:  Some filters in VTK used the UpdateExtent instead of the Extent in 
their execute method.  This caused a problem in a few cases because the 
UpdateExtent now keeps the value set by the consumer.  The fix for this is 
to replace image->GetUpdateExtent() with image->GetExtent() in the Execute 
method of your filter.  If the modification suggested in item 2 does not 
work,  suspect this problem.



4:  Some vtkStructuredPoints sources/filters (vtkSweptSurface) were not 
setting the WholeExtent in their ExecuteInformation methods.  This caused a 
problem because the WholeExtent is the default value of the 
UpdateExtent.  In some cases, the output image (if requested by the next 
filter) will crop the image to only include the UpdateExtent.  The solution 
to this is to simply add a ExecuteInformation method that sets the whole 
extent.



Now for the less common problems (which might still provide insight ... ).

5: One structured points source (vtkStructuedPointsReader), in its 
ExecuteInformation method, called:
this->GetOutput()->UpdateData(this->GetOutput());
this->GetOutput()->SetWholeExtent(this->GetOutput()->GetExtent());
This was done to avoid reading the header separately from the data.  It 
caused a problem because the UpdateData was cropping the output based on a 
whole extent that was not set yet.  The solution was to call:
this->GetOutput()->vtkSource::UpdateData(this->GetOutput());
to avoid the cropping (in the information pass) in 
vtkImageData::UpdateData(...).

6: vtkImageToStructuredPoints used to slide the Extent of the image so that 
it started at 0.
For example:       extent 128 255 128 255 128 255
would become:    extent 0 127 0 127 0 127
and the origin would be modified appropriately.
This slide no longer occurs.  Remarkably this only affected one filter in 
VTK.  vtkMarchingSquares assumed the extent started at 0, so it's point 
computation was compromised.
Although this only occurred in one filter in VTK, it has the potential for 
being the hardest to fix.


I hope this helps you.

Charles.