Setting color parameter in add_labels causes long execution time
#3852
Labels
bug
Something isn't working
performance
Relates to performance
probably solved
Issue that may be solved but requires confirmation
Comments
|
Thanks @kolibril13 for the report. This is due to the way labels colors are calculated. It should be fixed once we map labels to colors in the shader as proposed in #3308. Unfortunately it's not a trivial fix, but I think we are close to getting it working. 🤞 |
|
On 0.4.18 that cell with red/blue gives me 2.4-2.5 s per run. If I use the 2nd notebook to check toggle to 3d, also on 0.4.18: Adding the seed layers (in 2D): 0.3s So no performance difference really between the two color cases -- i'm tempted to close this. On 0.4.19rc3 I get: For the 2D switch to 3D case: @jni @Czaki that 2nd case on 0.4.19rc3 to me is a regression. Adding a layer in 2D should be as fast as possible. Seems like a warmup (numba?) there, but then toggle to 3D is instant. This is nice, but I think the other way around is better, as a moment to toggle to 3d might be expected, while adding a layer should be fast. Edit: I uninstalled numba (04.19rc3) out of curiosity and now with the red/blue layer I get: On |
psobolewskiPhD
added
the
probably solved
It was fixed in #6571. Not cherry-picked yet.
In #6602 I have added caching numba code between sessions. Could you play with it? |
|
Thanks for the rc testing @psobolewskiPhD, I hope we can make use of your services again in a couple of days for rc4! 😅 But in the meantime, yes, I think this issue can be closed! 🥳 |
|
main with both #6602 and #6607 merged, with numba: Adding in 2D toggle to 3d So a bit better... Edit: also I can confirm that #6542 fixes the issue with |
|
Another thing to try @psobolewskiPhD @kolibril13 is to use uint8 or uint16 data — that does not depend on conversion by numba (or any other format — it is viewed directly on the GPU) so should be much faster. |
|
with #6617 without Numba installed, with partsegcore-compiled-backend (conda-forge): |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🐛 Bug
Changing the color of a 3D mask with
viewer.add_labels(x, color= {1: "blue"})results in a 3x longer execution time, then setting the color by a random seed e.g.viewer.add_labels(x, seed=0.4). Here is a screenshot:Currently, it is more performant to guess a random seed that creates the color blue, then to set
bluein the first case. It would be great if there was a solution to make this method faster.To Reproduce
Here is the code, that I ran in a VS Code notebook:
Expected behavior
Setting color by parameter should take the same execution time then setting color by random seed
Environment
napari: 0.4.12
Platform: macOS-12.0.1-x86_64-i386-64bit
System: MacOS 12.0.1
Python: 3.9.5 (default, May 4 2021, 03:36:27) [Clang 12.0.0 (clang-1200.0.32.29)]
Qt: 5.15.2
PyQt5: 5.15.6
NumPy: 1.21.1
SciPy: 1.6.1
Dask: 2021.12.0
VisPy: 0.9.4
OpenGL:
Screens:
Plugins:
Additional context
Produced output:
EDIT: Also trying to switch from 2d to 3d with custom color caused the extra time delay:
The text was updated successfully, but these errors were encountered: