New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Labels] IndexError after painting into 3D labels layer and toggling 3D #6518
Comments
psobolewskiPhD
added
bug
Something isn't working
priority-high
High priority issue
labels
Dec 6, 2023
Fixed bug in #6439 |
@Czaki you're a wizard. Works perfect with that PR branch. |
GenevieveBuckley
pushed a commit
that referenced
this issue
Dec 11, 2023
jni
added a commit
that referenced
this issue
Dec 15, 2023
…rect color mode (#6439) Closes #6518 Closes #6084 # Description In this PR, similarly to #6411, instead of using `float32` to pass data to the GPU there we introduce heuristics for choosing smaller data types, while keeping high performance. Instead of complex calculation of color in the shader, a precomputed texture array is used. To avoid repetitive texture calculation, the textures are cached in the `Colormap` objects. For data of type uint8/int8/uint16/int16 we do not perform any transform of data. We send them to the GPU as it is. This allows to reduce computational time. Based on experiments, the rendering performance is a little worse for uint16/int16 than for uint8/int8. But it may depend on the GPU. Also, using uint16/int16 means usage more GPU memory than for 8 bits type. Still less than current main. For datatypes using at least 32 bits, we add a preprocessing step where we identify a set of labels that are mapped to the same color and map all of them to the same value. This often saves enough space to fall back to uint8/uint16. It allows using a smaller additional array, and use less GPU memory. If there are more than `2**16` distinct colors, then float32 is used, though performance will be reduced. We support only up to `2**23` distinct colors for now. For reduced memory usage, part of the functions used for data preprocessing are compiled using numba. We provide a version of the function that does not require `numba` but it limits the number of distinct colors to `2**16` and involves additional array creation (more memory usage). --------- Co-authored-by: Juan Nunez-Iglesias <jni@fastmail.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Lorenzo Gaifas <brisvag@gmail.com> Co-authored-by: Andy Sweet <andrew.d.sweet@gmail.com>
Czaki
added a commit
that referenced
this issue
Dec 15, 2023
Czaki
added a commit
that referenced
this issue
Dec 15, 2023
…rect color mode (#6439) Closes #6518 Closes #6084 In this PR, similarly to #6411, instead of using `float32` to pass data to the GPU there we introduce heuristics for choosing smaller data types, while keeping high performance. Instead of complex calculation of color in the shader, a precomputed texture array is used. To avoid repetitive texture calculation, the textures are cached in the `Colormap` objects. For data of type uint8/int8/uint16/int16 we do not perform any transform of data. We send them to the GPU as it is. This allows to reduce computational time. Based on experiments, the rendering performance is a little worse for uint16/int16 than for uint8/int8. But it may depend on the GPU. Also, using uint16/int16 means usage more GPU memory than for 8 bits type. Still less than current main. For datatypes using at least 32 bits, we add a preprocessing step where we identify a set of labels that are mapped to the same color and map all of them to the same value. This often saves enough space to fall back to uint8/uint16. It allows using a smaller additional array, and use less GPU memory. If there are more than `2**16` distinct colors, then float32 is used, though performance will be reduced. We support only up to `2**23` distinct colors for now. For reduced memory usage, part of the functions used for data preprocessing are compiled using numba. We provide a version of the function that does not require `numba` but it limits the number of distinct colors to `2**16` and involves additional array creation (more memory usage). --------- Co-authored-by: Juan Nunez-Iglesias <jni@fastmail.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Lorenzo Gaifas <brisvag@gmail.com> Co-authored-by: Andy Sweet <andrew.d.sweet@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🐛 Bug Report
If you paint into a 3D labels layer and then toggle to 3D you get a spam of
IndexError: too many indices for array: array is 2-dimensional, but 3 were indexed
Traceback:
git bisect points to:
a6e1569
#6411
This does not occur on 0.4.18 or 0.4.19rc2
💡 Steps to Reproduce
In the GUI:
This script is a simple way to test:
Toggle to 3D, should be fine.
Go back to 2D, paint a dot anywhere.
Toggle to 3D, error.
💡 Expected Behavior
No error should occur, it should be possible to paint labels and toggle 3D.
🌎 Environment
napari: 0.5.0a2.dev430+ga59cdac8
Platform: macOS-14.1.2-arm64-arm-64bit
System: MacOS 14.1.2
Python: 3.11.4 | packaged by conda-forge | (main, Jun 10 2023, 18:08:41) [Clang 15.0.7 ]
Qt: 6.5.2
PyQt6:
NumPy: 1.25.2
SciPy: 1.11.1
Dask: 2023.8.0
VisPy: 0.13.0
magicgui: 0.7.2
superqt: unknown
in-n-out: 0.1.8
app-model: 0.2.0
npe2: 0.7.2
OpenGL:
Screens:
Settings path:
Plugins:
💡 Additional Context
First noticed by @melissawm here:
https://napari.zulipchat.com/#narrow/stream/298358-working-group-documentation/topic/multidimensional.20labels.20layer
The text was updated successfully, but these errors were encountered: