Closed RFSH closed 3 years ago
As part of this task, I was also looking at how different tile size and compression would affect the viewer app performance. I was looking at the list of images generated here.
While comparing, I was mainly interested in the "user experience" and whether the performance causes any issues for the users. I tried to do it as systematically as I could, but in the end, what I'm going to summarize is not completely systematic and mainly just my experience.
I used both Firefox and Chrome to do this comparison.
Since I'm not very familiar with what's the "expected" quality for the images, it was hard for me to tell whether the page is pending some images or not. So I ended up adding a spinner to the OSD viewer app.
For the multi-channel images, if the user quickly performs multiple actions (span, zoom, etc) and opens the channel control immediately, they will experience a delay. I suspect that's simply because the browser is running too many Javascript codes at the same time, as well as manipulating the DOM. This delay was visible in DZI images as well. It was not noticeable on single-channel images.
512 generates almost twice the many image requests as 1024 tile size for the same singular action. The total size of these images is smaller than 1024, but since all the images are small, the difference didn't affect the performance that much. On the other hand, since there will be a lot of requests generated at once, it will overwhelm the browser and therefore users can notice a delay in the loading of the images. So I would say 1024 tile size is better for user experience. Also, the mentioned UI delay is more visible for 512 images.
Going from compression 100 to 50, I didn't notice much of a difference. Looking at the browser console, it's reporting a smaller total file size (especially when the user is looking at the higher quality image, i.e., when they are zoomed in.) but the difference wasn't noticeable to me.
After processing images with the new format and moving them to iiif server, the mulit-channel images are not properly displayed. So in this epic, our goal is to have functional multi-channel images. We're going to do this in two stages:
First Stage (static configuration for channels)
Our goal in this is stage, is to be able to mimic what we didi for dzi images, for iiif images as well. We should also gather more information about channel support in OSD viewer that will help us with the second stage.
Second stage (dynamic configuration)
In this stage, our goal is to be able to get the channel information from database. This includes name and pseudo_color that should be used in place of the staticly defined colors in the OSD viewer code.
the tasks for this stage require more thought