Closed tobyhodges closed 2 years ago
Update: a decision on this should also allow us to address and close #78
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.
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.
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.
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.
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.
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.
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 |
:heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark:$ |
Napari | :heavy_check_mark: | :heavy_check_mark: | :grey_question:* | :heavy_check_mark:# |
HyperSpy | :heavy_check_mark: | :heavy_check_mark: | :grey_question:+ | :heavy_check_mark: |
$ 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
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.
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.
This issue was revisited in today's co-working session and consensus was to use matplotlib.pyplot.imshow
in conjunction with %matplotlib widget
as the viewer to avoid possible future deprecation of skimage.io.imshow
.
conda install -c conda-forge ipympl
will need to be added to setup instructions.
I'll just add that having gone through the materials for the first time, using skimage.io.show works fine for all the examples, although having to create a new fig and axes each time is a pain.
Thanks so much for the feedback @shaw2thefloor. Creating a new fig and axes is necessary to show the image in a new widget below the cell. It can be omitted, but then the image will show up in the previous widget. skimage.io.imshow
seemed to be a solution that is portable with minimal additional setup. We will be continuing to consider emerging alternative image viewers. Please don't hesitate to comment if you have any additional suggestions.
Now that every episode has been "Jupyterised" and all mentions of the old viewer have been removed, I am closing this.
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:
One option would be to merge #99, which switches to using
skimage.io.show
(usingmatplotlib.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.)