Replies: 1 comment 1 reply
-
Thanks for reaching out. And many thanks for the great work you did with PyQtGraph over the last years... it really helped us a lot. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello folks,
I maintain pyqtgraph, I see you use our ImageItem grpahics object, which is great. You may or may not be aware, but ImgaeItem's performance, can rapidly change depending on some of the attributes that are being passed in (dtypes, size of the lookup table, if you're using levels, the shape of the levels, etc etc). It actually got confusing enough that I was no longer aware which usages of ImageItem were "fast" and "slow", so I crafted a PR (about to be merged, but not yet) that tries to lay things out a bit better for what to try and what not do for performance:
https://pyqtgraph--3028.org.readthedocs.build/en/3028/api_reference/graphicsItems/imageitem.html#performance
Taking a quick peek at your codebase, I see you already has lookup tables of dtype uint8 and no longer than 256 elements:
enmap-box/enmapbox/coreapps/scatterplotapp/scatterplotdialog.py
Lines 492 to 502 in 676d779
Also looks like you're plotting data that is of type
uint8float, the only other suggestion I have is make sure you specify(EDIT:levels=None
levels=None
does not work with float dtype) levels limit to avoid auto-sampling.Since you have float dtypes, ...how is it not raising an issue w/o you specifying levels...
Anyway if there are other performance bottlenecks or questions you have regarding pyqtgraph, feel free to reach out.
Beta Was this translation helpful? Give feedback.
All reactions