DigitalSlideArchive/HistomicsUI

HistomicsUI has inferior rendering performance compared to the simple image viewer in DSA

andreped opened this issue · 3 comments

The simple WSI viewer in DSA is close to seemless. Extremely impressive. Using this viewer is great for simple quality assessment of the database. I believe the pathologists at my department will love this feature!

It also works well for different rendering vendors, such as OpenSeadragon, which I am more familiar with from another project, but the default GeoJS is also great!

However, I was surprised to observe that the rendering experience in HistomicsUI is a lot more laggy than the simple viewer in DSA. Is it because of all the extra stuff happening in HistomicsUI, such as all event handling on the right hand side (see figure below)?

It would greatly improve the user-experience if the viewer had performance closer to the viewer in DSA. Right now doing any annotation work in the HistomicsUI would be a pain.

Perhaps there is something I'm doing wrong on my end. Is there something I can set in DSA, in the docker-compose.yml or similar, to improve rendering experience?

Note that this was before rendering any annotations or anything like that. I just attempted to visualize the WSI, zoom and pan the view, with both viewing solutions.

Screenshot from 2023-02-26 14-48-16
Screenshot from 2023-02-26 14-49-25

On this file in Chrome on my weaker machine, I'm not seeing much difference -- 9 ms per animation from the large_image item page and 10 ms per animation from HistomicsUI. Can you quantify what you are seeing?

Can you quantify what you are seeing?

How do I quantify this? Nonetheless, I could do a screen recording demonstrating the difference. Can do that soon.

Just ran a quick test, where I used WSIs of different formats using both. All the OpenSlide test data WSIs worked seemlessly between both viewers. At least the delay is barely noticable (if any). I tried the CMU-1.tiff (Generic TIFF format), CMU-2.ndpi (Hamamatsu), CMU-3.svs (Aperio), and OS-1.vsi (Olympus) from the OpenSlide test data.

I also tried to use a local .vsi which is about 200k x 160k in the VSI format, and it also works great. I therefore redid the original experiment and observed that the delay was actually observed on a WSI that was originally in the VSI format but had been converted to TIFF (WSI snapshots above). LIkely something went wrong during this conversion and thus resulted in this issue.

The only reason why I used the converted and used this WSI in the first place, was because of this issue resulting in HistomicsTK failing to use the Olympus format during plugin analysis. However, when that issue is fixed, this will no longer be an issue either.

As there is nothing wrong with the viewers (as observed using the OpenSlide test data), this issue can therefore be resolved.