I don’t know how much there is to do about this in terms of performance optimization, but I’ve tried it now on both my laptop with 16 GB ram (no dedicated gpu) running Windows 10 and my workstation with 128 GB ram and an nVidia GTX 1080 TI (11 GB), and in both cases, the software grinds to almost a complete halt when I try to update annotations with the brush tool. We are talking 3-channel tif images of about 100 MB with detailed annotations. I’m not sure what else I can do. I don’t really have any viable alternatives to this software at this point. I can supply an example project if that can help in any way.
I think Pete has posted elsewhere that the slowdown is due to having very complicated annotations, which are designed to be flexible markers for large areas. That flexibility is great since we can edit annotations, unlike detections, but also is much harder to process when they have a large number of vertices.
If you are pushing the program like this, you may want to try drawing a second annotation and subtracting them, or smoothing/simplifying your annotation before editing.
For clarity, is this 0.2.0m2?
Yes, it is m2. I remember him writing something along those lines. I just assumed that supplying it with more processing power and memory would alleviate this issue, but alas. I tried running the “split annotations” function, but that definitely did not help the situation for me, partly because I have unwittingly created a lot of one-pixel annotations in a drawing application before importing them to QuPath.
My original answer is here.
QuPath annotations are vector-based and it sounds like you want a whole slide annotation program that is raster-based. Potentially support for raster annotations could be added to QuPath one day, but it would be a big task and is not something I am working on.
With v0.2.0-m2 some aspects of working with annotations should now be substantially faster, but not all. Ultimately, using the brush tool with very large annotations can mean interactively combining shapes with many thousands of vertices, then painting these shapes - all within the same JavaFX application thread.
More memory and power will not resolve the issue, because GUI-related activities (including handling mouse events and painting) must all be handled on the same application thread.
Splitting annotations should help in some circumstances, but having lots of one-pixel annotations will certainly make the performance far worse. To maximize your use of QuPath currently, you will want separate annotations, each with a moderate number of vertices (a few thousand should be fine) - and no unnecessary annotations adding to the computational effort unnecessarily.
Yep, ahah, someone just commented on that thread here: https://github.com/qupath/qupath/issues/267
Made it easy to find just now.
If it is a single annotation, I think this script might help if it can handle your annotation… or it might crash and burn. If it can run, most importantly, you could run for batch and leave the computer going overnight. If it works, your annotations might be easier to deal with in the morning. Make sure to get a good feel for the size annotation you want to remove by creating some annotation objects and looking at their size. Easier to test that way first rather than iterating with the script.
Yes, I remember that answer, but thank you for clarifying how qupath handles the annotation process. That really explains everything. This is progressing outside the scope of what I can expect help on, but do you happen to know any raster based annotation tools with touch/drawing tablet support?
That script definitely looks interesting! I will have to take a look at whether or not it will be of help to me.
I don’t, but see Best tool for manually identifying objects of more than one class?
If I launch ImageJ through QuPath, does the JPen library then work with ImageJ or would that require a rewrite of the tools in ImageJ?
Why not try it and find out that way…?
Yep, I don’t have anything to test that either.
I gave up and started using Photoshop instead. It’s expensive, but luckily my PI is paying.
I was thinking if you could perhaps implement a scalable way to handle the regions in a more efficient manner. For example, if I zoom in to a very small region (e.g. 500x500 px) and I want to edit a part of a region in this small view, wouldn’t it then be more efficient to have the software do a sort of view cropping (maybe include a border to avoid weird clipping at the edges), so that the region outside the view is ignored during the editing and then stitched back together once the mouse button is released.
I don’t know how difficult that would be to implement, but I imagine it would make it a lot faster to edit complicated regions, at least when zoomed in. It was just a thought that struck me today, so I figured I might as well pass the suggestion
Glad you found software to do what you want.
There may be ways to improve the efficiency of QuPath for what you want, although it’s not totally clear to me what you do want (I don’t think you’ve posted any screenshots or detailed information about your images; I don’t know if 100 MB is the raw data size or compressed file size).
In any case, it would not be straightfoward. It’s possible (and often useful) to change the field of view and magnification while editing a region. This would add considerable complexity to any cropping code, and the calculations to both crop the ROI and reassemble it later may be expensive also.
I don’t think the greatly increased complexity is worth it for something that may or may not improve performance a bit in the specific case where you have very detailed and large annotations that you want to edit with a brush or wand tool. As outlined in previous posts, there are other ways you might approach things using QuPath… or, indeed, you can switch to Photoshop - which matches with my raster-based suggestion.