[vtk-developers] 64-bit indexing of vtkImageData

David Gobbi dgobbi at atamai.com
Tue Jan 18 11:09:53 EST 2005

On Tue, 18 Jan 2005, Ken Martin wrote:

> > When VTK was switched over to vtkIdType so that 64-bit indices into data
> > arrays became possible, vtkImageData was overlooked and even in VTK 4.5 it
> > isn't possible to have image data over the 32-bit size limit.
> >
> > I'd like to add 64-bit image indexing before VTK 5 is released, and I
> > want to solicit comments about how aggressive the change should be.
> > I think that the best approach is for increments to be stored as
> > vtkIdType, but perhaps extents and any image integer coordinates should
> > also be converted to vtkIdType.  It isn't absolutely necessary for
> > extents to be stored as vtkIdType unless people will be dealing with
> > images that are more than two gigavoxels across in one of the three
> > dimensions.
> In general this sounds good and makes sense. Certainly increments (and
> related number of cell type values) should be vtkIdType.
> You are right that extents/coordinates are more of a question. We clearly
> should support images with more than range-of-int cells. Do we want to
> support datasets that have more than range-of-int pixels on a side? Beats
> me. I have a hard time imagining an image that is more than 2 gigapixels on
> one axis but maybe others have comments ideas?

Thanks for the reply, Ken.  You stated the question more eloquently than
I did.

There are two arguments against vtkIdType extents:
1) Efficiency: I took a quick look at the AMD64 optimization guide
   - 32 bit multiply has lower latency than 64 bit multiply
   - 32 bit ops reduce both code and data size, which means better
     use of cache
2) Much more VTK code would have to be changed than if only the increment
   type is changed

So I'll proceed with the increment changes but keep one eye on the list.

 - David

More information about the vtk-developers mailing list