Description
We have several places where we need to understand or control how itk is ordering files into a volume. This could look like one utility that creates an ITKImage and has methods to query for the tags for a certain slice, or a mapping of filenames to slice indeces exposed in readImageDicomFileSeries. Here are a few examples of where we need this capability
Axial Obliques
There is a very common type of MR wherein the tech is attempting to cut directly through a spine disc segment. The resulting volume is an axial view where each slice is at a different angle from the slice before it. Tag level data lets us localize these series against other images by giving us a normal vector for each slice. Right now we just take our best guess at ordering to show localization lines.
AI Applications
Several of our AI applications act on the same source DICOM file series. They might produce an artifact like an NRRD of the volume with certain landmarks indicated. In order to show this in sync with the proper image slice in our viewer, we need to understand what source file corresponds with each slice in our ITKImage.
Offloading processing to different layers
There are hard browser memory limits that it is easy to hit with ITK on the client. This necessitates running some or all of the pipeline on the server side. If we are running our tag processing and volume processing to different layers, we need some mechanism by which to ensure ordering is consistent.