Hi, are there any plans to improve the Histogram responsiveness from Volumes module? I have a rather large volume, with dimensions 923x932x1771 and the Histogram is just too slow to be usable in this case. I am using nightly 13.0-2020-12-13 r29523.
Edit:
I subsampled the volume down to 923x932x50, and it is still very slow to update when changing the threshold sliders.
Histogram in Volumes module is just an illustration. How do you use it?
How long does it take to compute it?
How often does the volume change?
How much physical RAM do you have?
What is the scalar type of the volume?
You can get a good approximate histogram with a small sample, like 1%. We should probably do this if the volume is large.
It is not necessary to recomputed the histogram when the window/level slider is moved. Maybe it is unnecessarily recomputed we just did not notice it (because usually it is very fast), but maybe it is slow because of slice view or volume rendering updates. How do you know that it is slow due to the histogram computation?
Hello Andras and Pieper, thanks for your reply.
These are my system specs:
Microsoft Windows 10 Pro
Processor AMD Ryzen 7 2700 Eight-Core Processor, 3200 Mhz
RAM 32 GB
GPU NVIDIA GeForce GTX 1660
SSD ADATA SU630
How do you know that it is slow due to the histogram computation?
Because when I close the Histogram collapsible button, the sliding action of the Threshold flows much smoother.
Testing with the sample data “MRHead” (256x256x130), the Threshold sliding response (and Histogram observed region update) is fast, but when testing with the sample data “CTA Abdomen” (441x321x215), the response already becomes poor (while the Histogram is being shown).
You can get a good approximate histogram with a small sample, like 1%. We should probably do this if the volume is large.
The volumes I work with are large (900x900x1700 for example). Maybe it would be nice to allow the user to set this sample percentage.
Thanks for the additional information. I’ve checked the code and indeed qSlicerScalarVolumeDisplayWidget::updateHistogram() is called each time the display node is changed (e.g., you change window/level). This is of course unnecessary and may cause significant slowdown for huge volumes.
To fix this, a check could be added and skip building of the histogram if input image data pointer and modified time (MTime) did not change since the last build. For this, last used image pointer and modified time has to be saved in member variables.
It would be great if you could fix this and send a pull request. Should be just 10-20 lines of code in total.
Right now I was only programming in Python. I’ll find some time to setup everything for C++ and report back here about the development. Thank you 
One question: how the updateHistogram function is called when the window/level slider (or threshold slider) is changed (where in the code the connection is made)?
Edit: is this the answer?
That looks like the right place, yes.