layer.current_3d_data

🚀 Feature

Hi all,

I’d like to request/suggest a new feature: A function decorator and/or property of any layer that returns the currently selected 3d dataset.

Potential interfaces:

image_3d = layer.data3d(viewer)  # returns data of currently selected timepoint in viewer

@time_slicer
def my_filter(image: ImageData, viewer:Viewer)
   # image is garanteed to have 3D shape because time-slicer crops out the current 3D from a given 4D dataset

@time_slicer
def my_filter(image_layer: Image, viewer:Viewer)
   image3d = image_layer.data3d() # time_slicer inserts that function into the layer and/or refreshs it using the provided viewer

Motivation

In practically applied volumetric image processing, there are many applications for 3D filters. Even though libraries such as SciPy support nD filters, 3D filters are more common. I’m suggesting a better interface to apply 3D filters to the current timepoint in napari, and e.g. updating the result when the timepoint changes.

Pitch

I maintain a couple of libraries that offer functions for processing 3D image and label data. Most don’t support 4D datasets. Hence, I came up with napari-time-slicer which uses a function decorator to modify parameters that are passed to a function: In case a 4D dataset is passed to a function via magicgui, it crops out the current 3D data. Additionally, the decorator comes with some event handling which causes update of image layers in a thread_worker when the user changes the current timepoint.

While this approach is powerful, I’m hitting limitations:

• This is only compatible with functions consuming ImageData and LabelsData. I have no solution for Layer input.
• The code for this spreads multiple libraries including napari-workflows and I would like to centralize things. I think it makes sense to make this possible in napari core.

Alternatives

Napari layers have a private member _data_view which fulfills a similar purpose as discussed here. I think though that the functionality I mentioned should not be dependent on the current view (2D or 3D) the user selected. It should more depend on what the developer thinks is relevant, e.g. the current 2D, 3D or 4D, … dataset.

Additional context

[jni]

@haesleinhuepf I feel your pain, but I hope that we can fix this as we work on asynchronous slicing, which will require a functional API for slicing, something along the lines of

def slice(self, indices) -> SlicedLayer:

The sliced layer object would be guaranteed to be 2D or 3D, depending on the indices.

I do see your point about the view and the processing not necessarily matching in dimension. Will think about the best API for that… Thanks for the issue…!

[perlman]

@haesleinhuepf I feel your pain, but I hope that we can fix this as we work on asynchronous slicing, which will require a functional API for slicing, something along the lines of

def slice(self, indices) -> SlicedLayer:

@jni You’ve sold me on slicing. 😉

The sliced layer object would be guaranteed to be 2D or 3D, depending on the indices.

Why make this guarantee? The indices could specify nD. (But not when using the current view obviously.)