You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
>>img_graphic.data=0---------------------------------------------------------------------------ValueErrorTraceback (mostrecentcalllast)
InputIn [44], in<cellline: 1>()
---->1iw_cnmf.plot.graphics[0].data[0] =0File~/Insync/gdrive/repos/fastplotlib/fastplotlib/graphics/features/_data.py:114, inImageDataFeature.__setitem__(self, key, value)
110def__setitem__(self, key, value):
111# make sure float32112value=to_gpu_supported_dtype(value)
-->114self._buffer.data[key] =value115self._update_range(key)
117# avoid creating dicts constantly if there are no events to handleValueError: assignmentdestinationisread-only
But we are only showing a part of the entire large memmap in those cases so we could just set the texture data entirely if it's a lazy-loading type, maybe a nice way to do it would be to have something like:
Refactor indexable graphics, don't have __call__ to get the data under the buffer, make it explicit so it has to be feature.buffer.data to get the data.
A kwarg for isolating buffers with this type of usage:
common_buffer=None - all buffers are isolated from input arrays
common_buffer="data"
common_buffer=["data", "colors"] - when using non-isolated buffer for colors, an array must be provided for the colors.
If a common buffer is specified for any feature, then the dtype of the input array must be GPU compatible else raise
I just noticed that before #143 when we initialized any
GraphicFeature
, the data were being copied to a new array because ofastype(np.float32)
which hascopy=True
by default: https://github.com/kushalkolar/fastplotlib/pull/143/files#diff-e9a4f655a73cc26eb39868b9b4f44940cccfa247f6c433559cec77954383a198L46We need to think about how to properly deal with updating the data in these buffers when the arrays are read-only, such as numpy memmaps:
Trying to assign, results in the following:
But we are only showing a part of the entire large memmap in those cases so we could just set the texture data entirely if it's a lazy-loading type, maybe a nice way to do it would be to have something like:
The text was updated successfully, but these errors were encountered: