Proposal to add orientation to vtkImageData- Feedback Wanted

Development
42

It is already implemented and available in VTK9.

1 Like
43

Oh I see it. Thanks for letting me know @lassoan

44

A lot of support for it is there and more has been added over time. There are still a couple significant places where support for oriented images is missing. I believe ImageReslice (a replacement as backwards compatibility turns out to be tricky) is one of the big ones and is on my todo list. I’ve been sort of avoiding it as in the back of my head I want to create a new image data class that defaults to cell data (or add a flag to the current class).

People think of pixels as cells and our current notion of pixels as being point samples creates confusion. People tend to expect 100 pixels at 1mm per pixel to create an image of 100mm, but in VTK 100 point samples on an axis equals 99 cells on an axis. And when you draw those cells they look like 99 pixels when people expect 100. I think moving to cell data for pixels would get us to a more common representation. The image would have 100 pixels of cell data, 100 cells, and 101 points defining the boundary of those cells (on an axis).

45

I’d advise caution, Ken. It’s not as if the notion of pixels as point samples is unique to VTK. The same is true of ITK as well, and as far as I understand, of medical imaging in general (including how pixels are defined according to the DICOM standard). Pixels as cells is more of a computer graphics concept, and I’ve always thought of VTK as more of a scientific visualization package than a computer graphics package.

Edit: my original reply said “point cells”, that was a typo. I meant to type “point samples”.

2 Likes
46

I agree, “voxels as point samples” is the usual way of representing volumetric image data in medical imaging and changing it might cause lots of difficulties.

There are a few small details in VTK may not be optimal, but these could be resolved without changing how voxels are defined. For example:

  • extent going from minimum_index to minimum_index+size-1 (instead of the usual minimum_index+size)
  • and image bounding box reported to be minimum_voxel_position to maximum_voxel_position (instead of the actual minimum_voxel_position-spacing/2 to maximum_voxel_position+spacing/2)

I don’t think it would be a good idea to change even these, as although these are not intuitive, they are used consistently throughout VTK. It is easier if users learn these few quirks.

1 Like
47

Another reason to think of images in terms of point samples is that it naturally extends the idea of images to other sampling patterns. For example, random sampling is a hot topic in imaging science right now. Random samples don’t work well as cells.

I think that where VTK made its mistake, historically, was to define a vtkImageData class that was distinct from vtkStructuredPoints. There should have only ever been structured points, and vtkImageData should never have been brought into existence. Ideas like streaming should have been brought into the geometry pipeline early on, and the geometry pipeline vs. image pipeline split in VTK should not have occurred.

Edit: similarly, I think vtkVoxel and vtkPixel were poorly-chosen names. Cells are very generic things, but the names “voxel” and “pixel” very specifically denote elements of an image. These cells types should have been named “vtkCuboid” and “vtkRectangle” to indicate that nothing about them is image-specific. The only thing important about them is their geometry.

1 Like
48

Works for me, I think some people expect that extra 0.5 spacing but if we view it as a point sample then the 1/2 spacing isn’t even quite right as it really is based on the point spread function of the sampling hardware/function which can be different from the spacing of the acquisition. Since we pretty much ignore the PSF in VTK then it’s fair game to just consider the bounds the actual bounds of the acquisition points. But still throws people all the time. And yes /agree on the pixel/voxel naming.

1 Like