[vtk-developers] How do I reliably the origin of a vtkImageData in VTK 6?

[Cory Quammen]

[Reposting to the VTK developers list]

I'm using VTK at commit 5754065bad83bf9cbcfbcfa72ecfbbed91f277db (July
13, 2012).

Goal:

I'm attempting to something with a vtkImageData object outside a VTK
pipeline that I think should be straightforward (rasterizing a
sphere). To do this properly, I need to know the origin and spacing of
the vtkImageData object produced from a filter.

Problem observed:

When I ask a vtkImageData about it's origin, the answer I get depends
on whether it has been processed by a downstream filter or not. Here's
what I'm seeing.

I have a short pipeline sketched here:

vtkExtractVOI * extractor = vtkExtractVOI::New();
extractor->SetInputData( image );
extractor->SetVOI( voi ); // Assume voi[0] > image->GetExtent()[0]
extractor->Update();
// extractor->UpdateWholeExtent(); // using this makes no difference

vtkImageData * subImage = extractor->GetOutput();

// Ask subImage for it's origin
double originBeforeWrite[3];
subImage->GetOrigin( originBeforeWrite );

// Save the extracted region to a file
vtkMetaImageWriter * writer = vtkMetaImageWriter::New();
writer->SetFileName( ... );
writer->SetRAWFileName( ... );
writer->SetInputData( subImage );
writer->Write();

// Ask subImage for it's origin again
double originAfterWrite[3];
subImage->GetOrigin( originAfterWrite );

Now, when this code is executed, originAfterWrite[i] != originBeforeWrite[i].

This is disturbing.

I'm guessing writing subImage to a file triggers an update to the
origin in the pipeline that then gets set back in subImage, and that
explains why originAfterWrite[i] != originBeforeWrite[i]. Shouldn't
the origin returned from subImage->GetOrigin() be updated when I
invoke extractor->Update()?

If not, could you please advise me on the proper way to get the origin
from a vtkImageData that is produced as the output of a filter? I
looked in the VTK 6 migration guide, but couldn't find anything
pertaining to this question.

Thank you,
Cory

-- 
Cory Quammen
Research Associate
Department of Computer Science
The University of North Carolina at Chapel Hill