Display slice by slice

[paskino]

Slice by slice viewer

To be able to display a huge image data in full scale we could display one slice at a time. This would imply that we rely on the data to not be fully loaded in the viewer, rather the viewer gets passed a reader and the reader provides the appropriate slice on request.
This could be achieved with cropped readers.

However, this also requires some changes in the viewer:

1. The viewer assumes that the member img3D is a vtkImageData
2. img3D is then passed as input to a vtkExtractVOI filter to create the vtkSlice object
   that is rendered on the scene
3. The actual slicing is triggered by mouse wheel event, which does the following:
   1. setActiveSlice is called with the new slice number that one wants to select. This actually just stores an integer
      in list of length 3.
   2. updatePipeline is called, which in turn calls either updateImageWithOverlayPipeline or updateRectilinearWipePipeline
      depending on which visualisation mode we are using. Both methods trigger updateMainVOI which sets the extent
      for vtkExtractVOI to the slice that we want to show and the appropriate slice is extracted and rendered.

Proposed solution

If we need to rely on a file reader to render only part of the data we need to be able to pass a reader (or an output port) to the viewer. The viewer should be able to understand if it's passed a vtkImageData or a reader, and in the latter case modify img3D with the slice that's requested.

This requires to make img3D a property

    @property
    def img3D(self):
        if self._reader is None:
            return self._img3D
        else:
            self._reader.Update()
            return self._reader.GetOutput()

I tested this with a tiff dataset and a npy file.

Remaining issues

• finish for input2
• handle slicing in the other directions than Z. Currently only Z slices are allowed by all readers, with HDF5 able to slice in all directions (performance may change based on chunking and compression). Shall slicing in X and Y be disallowed when the reader does not support this and raise an error?
• add functionality to viewer3D. Do we need it there? Wouldn't it be better to pass the 3D viewer a downsampled version of the data? As a matter of fact a volume render would be rather impossible in full scale.
• test with the HDF5 cropped reader
• add SetExtent method to all cropped readers, possibly raising an error in case the required extent cannot be provided
• viewer annotation returns extent 0, as it uses img3D.GetExtent() which returns 0 for 1 slice.
• viewer starts at slice 0 as it uses img3D.GetExtent() to figure out the centre slice.