Sorry, something went wrong.
|
I think we can use the a[np.newaxis] method as you mentioned, it returns views of the array which makes sense: a[np.newaxis, np.newaxis].ctypes.data == a.ctypes.data Currently ImageWidget uses the lowest "t" and/or "z" dimension sizes to set the max bounds "_dims_max_bounds" for the ImageWidget and the sliders. If we instead set _dims_max_bounds based on the largest sizes in each dimension by modifying this bit: fastplotlib/fastplotlib/widgets/image.py Lines 540 to 546 in 5ec3fb2 and then in @current_index.setter fastplotlib/fastplotlib/widgets/image.py Lines 218 to 221 in 5ec3fb2 when iterating through each individual data array, we do something like this to prevent out of bounds indices for the data arrays which have fewer "t" or "z" items (ex. corr images) than the other data arrays (ex. movies). current_index = dict()
for k in self._current_index:
dim_ix = dict(reversed(ALLOWED_SLIDER_DIMS))[k]
current_index[k] = min(self._current_index[k], data.shape[dim_ix])
It'll be generally useful anytime the shapes are very different. Might want to raise a warning in the constructor and set_data() to just let the user know that the array shapes are different and to expect this type of behavior (ex. sliding through data using the "t" slider will only change the graphic data if data exists at that position along that dimension, else it is ignored and the other data arrays are updated). |
Sorry, something went wrong.
|
@kushalkolar It seems the tests for pre-existing cells in image_widget_test.ipynb are failing. The rgba_to_rgb function seems to complain that the input has 2 indices but 3 indices are indexed etc. Let me know what you think, maybe we need to update the rgba_to_rgb function? Once we have that fixed, I can re-run to generate + update new screenshots. |
Sorry, something went wrong.
|
I've made this a full PR from the draft so the CI will run on GitHub actions, we can check the result tomorrow. |
Sorry, something went wrong.
Closes #284