search

DeepMicroscopy / SlideRunner

SlideRunner is a tool for massive cell annotations in whole slide images
GNU General Public License v3.0
75 stars 10 forks source link

Guided mode speed improvement #16

Closed mingrui closed 6 years ago

mingrui commented 6 years ago

I was wondering if the speed in guided mode can be improved by pre-loading prev and next window?

maubreville commented 6 years ago

For sure. But I think that the overhead would be not too small. Is it a major problem?

mingrui commented 6 years ago

I feel it's more a problem when I'm at the edge of a larger patch and the next window is really far away.

If the prev / current / next patches are all connected (for example if I'm in the middle of a larger patch), then it's not a major problem.

maubreville commented 6 years ago

You are absolutely right. In order to circumvent this, I guess SlideRunner would have to do some kind of prediction of what could be interesting to the user.

In fact, I recently got the feedback that the whole buffering made it slow :( So I was also thinking that the cache should only be updated in the background.

mingrui commented 6 years ago

Regarding the buffering, I was looking at the code and trying to get buffering to only run in background, using python's multiprocess (I'm a noob at python, so I may be using the wrong library). I sort of got it working with map_async, but don't really know where to put it and replace your current caching function, will create a branch later tonight for you to take a look at.

Here is a quick gist for you: https://gist.github.com/mingrui/119de48a79ca1e7ebce17233abbe71bb

My problem is when the zoom level is about 20.0x(my slide's highest zoom), it's the slowest, takes about 2 to 3 seconds for openslide's read_region to run. (as a comparison, 19.0x zoom or 40.0x zoom only takes less than 0.5 sec) I think this is because the zoom level is at my highest but also the field of view at 20.0x is very large(so compared to 19.0x, field of view is the same but zoom level is one level higher, compared to 40.0x, zoom level is the same but field of view is much larger), so it's loading a rather high resolution and large region.

I'm wondering if we can fix this by loading a dummy image first (QuPath seems to be handling this by using a lower res image as a stand-in) before loading the actual real resolution image. This way mouse dragging event will not be blocked. I think I can wait for 2sec loading time, but what's frustrating is the input gets blocked, and after image loads, there is a random jump to catch up to my mouse drag position.

maubreville commented 6 years ago

I was thinking along the same lines. I will try out your gist and think further about caching a low-res version of the image ...

Thanks for you contributions!

maubreville commented 6 years ago

I see that you are using multiprocessing to start the new thread. Unfortunately, this leads into problems when using cv2. I tried to solve it a bit different now. Took me a while ;-)

maubreville commented 6 years ago

I now did it a bit different than you proposed, still it was a very good inspiration - thank you! Do you like the current implementation?

Now an overview map (largest available downsample in the WSI) is kept all the time in-memory and used to preview until loading of actual image has been done.

mingrui commented 6 years ago

I tried it quickly and feel it's much improved, I will do more testing and look into the code tonight.

Another thing I just thought about, is it easy to implement a setting (even if it's just a variable I can change in the source code, without any UI) to specify how much ram I can allow sliderunner to use?

For example if I am using a laptop, I can't really fit an entire wsi slide into memory. But on my workstation, with 128gb ram, I can actually fit the entire slide into memory.

Maybe we could add a background thread to load the entire image into memory without disrupting the foreground work. And presumably once the background thread finishes, we can just swap the loading full resolution image.

But this is a very niche feature for powerful workstations with lots of ram... so not a priority

maubreville commented 6 years ago

I think it would be possible, however, as you pointed out, it's a bit of a nieche. Me and my collaboration partners do not have such a system at hand, but I can hint you to where you would have to pre-fetch the complete slide, should you need it.

Meanwhile, I will close this issue, because I feel it's been solved.