Multi-channel MVP

[RFSH]

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.

• [x] Fix the broken links in regression tests.
• [x] Figure out why channels are not in order in iiif images and why the "Hue" property is missing.
• [x] Make sure the overriding rules for the query parameters are consistent. Query parameters should be used in place of other values.
• [x] Find more information about how osd viewer handles channels and document it in this wiki ( (#48). I added a channel section in there with a TODO. Add all the information that you gathered in there. Please avoid just adding a link or screenshot without any description. You should explain as much as you can. These are some of the questions that we need an answer for:
  • When do we see the channel controller (the one that allows you to change)?
  • What are the attributes that OSD viewer derives from xml file for the channels? What are the minimum required attributes?
  • Used by who (osd or osd viewer)?
  • Have an example of XML and info.json to compare their attributes. What is expected in each one? How is each used?
  • How does the color mapping is done in OSD viewer? Are the input images in greyscale?
  • What does the code do when the hue is changed?
• [x] If channel name is not defined for an image, we should just use the channel index (starting from 0)
• [x] Refactor the code to use proper dzi and iiif terms.
• [x] Process multiple iiif images on top of each other (as different channels).
• [x] Fix the color mapping of channels to use an rgb color instead of just red, green, or blue.
• [x] Upgrade the OSD version and make sure everything is working properly.
• [x] Investigate why the scale is not showing for iiif images.
• [x] Investigate adding thumbnail to iiif images.

---

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

• [x] Use channel number (assume position otherwise)
• [x] Allow pseudo_color in query paramer
• [x] Get the channel info from channel table.
• [x] Get all the image and channel info from the channel table.

[RFSH]

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.