Define an "index" type that encapsulates one frame of one instance about vtk-dicom HOT 3 OPEN

One problem with adding this index type is that it leads to a large number of similar get methods:

GetAttributeValue(tag)
GetAttributeValue(file_index, tag)
GetAttributeValue(file_index, frame_index, tag)
GetAttributeValue(vtkDICOMIndex tag)

The vtkDICOMMetaData interface is already too complicated. There's something nice about keeping the file and frame indices separate.

Perhaps the best solution is to make a new adapter class, like the vtkDICOMMetaDataAdapter. It could expose an interface that is specific to its use alongside vtkImageData (hence: slice, component indices rather than file, frame indices). Also, the adapter could keep the FileIndexArray and FrameIndexArray.

The idea here is that this adapter class would provide a "view" of the meta data that is better matched to its use within the VTK visualization pipeline.

Here's a crazy plan. I can turn the current MetaData class into something akin to vtkDICOMItem, i.e. no longer derived from vtkObjectBase, and I could rename it to vtkDICOMAttributes. Hence, it would become much less vtk-specific. Then, vtkDICOMMetaData would become a vtk-specific view to vtkDICOMAttributes. Indices would always be slice, component and enhanced vs. legacy files would "look" the same.

from vtk-dicom.

The adapter idea is very appealing to me, especially because I could simply modify the existing vtkDICOMMetaDataAdapter class. It would do much the same thing as the current adapter class, but would be able to take two indices: slice and component. It might be necessary to include the vtkImageData as part of its construction, so that it knows how many components the data has.

I suspect I will have to use two indices for component, "component j of n", like in my current GetFileIndex method. So it would be GetAttributeValue(int i, int j, int n, vtkDICOMTag attr). Alternatively, the value of "n" could be set in the adapter's constructor, or gotten from the image data information.

from vtk-dicom.

No progress on this yet (and it's 2017!) but here are some more thoughts.

The first, most important, consideration is that this new "index" type is going to be confusing to the users, so the only reason to add it is if it makes my own life easier when implementing sorting and so on.

Most users aren't going to care about the file/frame indices. Hence the utility of adapter classes, because the adapter can provide whatever sort of an indexing scheme is most applicable. An adapter can even make a vtkDICOMItem look like a vtkDICOMMetaData. Adapters can be made to be read-only (certainly the easiest) or read-write. People can write their own adapter classes if there isn't already an adapter that suits their needs.

from vtk-dicom.