Use a different image viewer

[tobyhodges]

As noted elsewhere and reported by @erickmartins in #99 the skimage.viewer viewer has been deprecated. Other issues (#73 & #66) have noted problems with that viewer anyway.

We should choose something else that is:

• easy to install regardless on any reasonably modern operating system
• adds few dependencies
• is stable and well-supported

One option would be to merge #99, which switches to using skimage.io.show (using matplotlib.pyplot.show "under the hood" unless I am mistaken). This will display images inline if using an interactive environment like Jupyter. If we decide to do that, the lesson content will need to be carefully updated to reflect the change. (See #130, but other changes are also likely to be needed.)

[tobyhodges]

Update: a decision on this should also allow us to address and close #78

[erickmartins]

Even though I did write the PR for using skimage.io.show - I'd say probably the best thing to do right now is to move towards napari. It does run on a separate window, but with napari.utils.nbscreenshot we can retrieve screenshots to be put inline, and with some magicgui you can have all the functionality that skimage.viewer plugins had. It's a significant rewrite, but I think any change of this magnitude will be a significant rewrite anyway.

[tobyhodges]

Thanks @erickmartins. The concern I had with Napari is how easy and reliable it will be as a dependency to introduce for the lesson: when I tried to install it to test it out on this lesson, I hit a problem where it clashed with the most recent update to MacOS. This is not a deal-breaker on its own - the problem was fixed quickly* and I have encountered plenty of similar issues with other open source tools e.g. Python libraries like Pandas - but it felt like a bad omen for something that The Carpentries will be relying on instructors and learners to be able to install for Data Carpentry workshops all over the world.

Perhaps I got unlucky, though? I happily admit that I am approaching this question without a weight of real-world image analysis experience, and will happily defer to the opinions and experience of others who do have it.

* edit to clarify: it was fixed quickly in the codebase. On the day, I had to give up on the installation and move onto a different project.

[bobturneruk]

I've been experimenting with HyperSpy as a possible alternative https://mybinder.org/v2/gh/AFM-SPM/hyperspy-eg/HEAD?filepath=hyperspy-spm.ipynb. Not checked on MacOS, yet, though.

[quist00]

Well I tried your code on my MAC, and it seemed to work fine.

This may be a complex enough discussion to hold until we meet, but having not used skimage.viewer extensively, I guess I don't know exactly what it is that we are trying replace. What is the killer feature for either hyperspy or napari that those extra dependencies bring to the table that we don't get by simply punting to skimage.io.show, which if it really is matplotlib.pyplot.show under the hood then we already have deep ongoing ties to it through other carpentry lessons.

[bobturneruk]

Agree. I'm not advocating HyperSpy particularly, just wanted to share it as an option. I think an important thing is to be able to hover over the image and see pixel co-ordinates.

[tobyhodges]

I think an important thing is to be able to hover over the image and see pixel co-ordinates.

This is the main thing we are after. It is a small thing but quite important, especially for those working with image data for the first time.

[uschille]

Perhaps it's useful to collect the different options and look at what environments they would work in. Feel free to edit and add to the table (we might want to check different OS as well).

	Python scripts	Jupyter notebooks	Remote Jupyter Lab/Colab (no X-server)	pixel coordinates
skimage.io.imshow	✔️	✔️	✔️	✔️$
Napari	✔️	✔️	❔*	✔️#
HyperSpy	✔️	✔️	❔+	✔️

^$ backend %matplotlib notebook
^# in external viewer
^* Requires Qt.
⁺ Requires Jupyter Lab extensions.

Test notebook: https://github.com/uschille/image-processing/blob/viewers/Viewers.ipynb
Test script: https://github.com/uschille/image-processing/blob/viewers/Viewers.py

[quist00]

I think an important thing is to be able to hover over the image and see pixel co-ordinates.

This is the main thing we are after. It is a small thing but quite important, especially for those working with image data for the first time.

What if we retained skimage.io.show as a default and used it in all cases where coordinates were not important. Then introduce our best deemed viewer in conjunction with an exercise where they will immediately be putting those coordinates into practice.

While having two viewers add to cognitive load, I think it does provide some benefits to both us and the learners.

1. It allows us to introduce the concept that the viewer used is a choice.
2. That many viewers they have to choose from have strengths and weaknesses.
3. That those strengths and weaknesses will evolve over time with quatlity/quantity of open source contributions.
4. In the event either of these viewers is deprecated or no longer the best, we have fewer places to make curriculum changes if they have these dedicated uses in our presentation.

[tobyhodges]

This was discussed at the Developer/Maintainer co-working session on 2021-08-12. The group agreed that we would use skimage.io.imshow for now, with the Jupyter magic command %matplotlib notebook to enable mouse hover-over for exploring image coordinates, intensity values.

We will also mention Napari in the lesson as an up-and-coming tool that can be very helpful for data with more than two dimensions. We will also monitor the development of Napari and consider adopting it if and when it is more stable.

Leaving this issue open until the relevant changes have been made.