Switch from OpenCV to skimage about image-processing HOT 27 CLOSED

well, how about using jupyter widgets? We could do something like (not tested)

def show_filt(sigma, low_threshold):
    io.imshow(feature.canny(img, sigma=sigma, low_threshold=low_threshold))
    io.show()

interact(
    show_filt,
    sigma=FloatSlider(value=2.0, min=1.0, max=10.0, step=0.1),
    low_threshold=FloatSlider(value=0.1, min=0.0, max=1.0, step=0.1))

from image-processing.

@k-dominik and me have stumbled upon some more inconsistencies between OpenCV and skimage:
In skimage, several functions convert the input image from uint8 (value range 0 to 255) to float (value range 0 to 1). For example, skimage.color.rgb2gray or skimage.filters.gaussian. This conversion is not done by OpenCV (I guess it converts to floats internally and casts back to uint8 before returning the image). We can see two options to deal with this

1. Use skimage.util.img_to_ubyte to convert the images back to the original datatype and value range. This has the upside, that we would not need to change a lot in the lessons.
2. Work with the float images instead. We would need to change more in the lessons and it might be conceptually harder to understand some of the lessons, because of the switch in dataranges, but it is cleaner to work with floats due to numerical stability.

from image-processing.

I suggest closing this issue - there are plenty of new, finer grained issues out there that cover specific aspects of the skimage based lesssons now (also the big PR was merged...)

from image-processing.

One issue I see is the OpenCV plotting functionality used, for example the trackbars.
It's certainly possible to reproduce this with skimage + matplotlib, but the options I know involve a lot more code, see this example.

from image-processing.

@k-dominik and me decided to merge our PRs into the branch skimage first, so we can get a general review from you guys before merging into gh-pages.

from image-processing.

Adding to the ipywidgets comment, should we consider reworking the "command line" bits of the lessons/episodes as well? Those will not make sense anymore with code relying on being run in a jupyter notebook.

from image-processing.

@constantinpape @k-dominik exciting to see this. Do you have a timeline / need any help on the conversion?

I'll be teaching some basic image processing to a small group in October and was interesting in re-using some of this curriculum, but would prefer to teach off of skimage and am happy to align efforts.

from image-processing.

@sofroniewn we are waiting on some feedback regarding switching from command line based exercises to jupyter.
Once this is decided, we want to do this soon. Any help in updating one of the exercises would be very much appreciated then. We will keep you updated.

from image-processing.

that's great @constantinpape I might make a fork and do some exploring myself, but will look out for updates from you here. using jupyter (and even binder!) is a plus as far as I'm concerned.

from image-processing.

I don't know how rigid this whole thing here is, but we might even consider using pandoc to generate jupyter notebooks from the individual markdown documents (and then go jupyter notebook slides for teaching, sky is the limit ;))...

from image-processing.

:-) I'd consider something like jupytext that makes the conversion between markdown and notebooks really straightforward, as agreed, it's preferable not to have actual notebook files in repos due to the diffing

from image-processing.

Sorry to be late to the discussion - just getting back from vacation and will also admit these details are a bit over my head as a (very) occasional Python user.

@mmeysenburg and @tessalea and I discussed the scripts vs notebooks issue and also got some feedback from the community. Most people said that they primarily used scripts (with many making use of notebooks for things like prototyping / testing and documentation), especially people who were moderately experienced in Python. We're currently considering this lesson as the first official intermediate level Carpentries lesson, so it make sense to bias the design towards intermediate Python users. (Learners would need to have attended a Python workshop before or check off a box that says they are comfortable with XYZ tasks in Python.) With that in mind, I'm in favor of keeping this lesson notebook-free, if that is a feasible option. I'm pinging @mmeysenburg and @tessalea here as well to see what guidance they can add.

from image-processing.

What about using the Slider widget in Skimage?

https://scikit-image.org/docs/dev/user_guide/viewer.html

from image-processing.

What about using the Slider widget in Skimage?

https://scikit-image.org/docs/dev/user_guide/viewer.html

sure, could also be used. I'm not a notebook evangelic (far from that) but for teaching I still think it's the best. So ideally we'd have a solution that works with both. The viewer will pop up, too, when instantiated in a notebook as a new qt window.

The viewer might be deprecated soon, so I'm not sure whether it's a good idea to build on it now: scikit-image/scikit-image#4081
We should probably consider napari right away.

from image-processing.

I'm partial to scripts for the lesson, personally.

As for the trackbar issue, maybe we can change the way we go about that part of the lesson. The goal is to give users a way to determine a good threshold value (or other parameter), so how about a script that simply goes through a range of values and saves (or shows, perhaps) the resulting images? For example, something like the attached OpenCV script. It takes an image filename, and start / stop / increment values for a range of threshold parameters. It outputs the images, which can then be examined to see which approximate threshold value would be best to use in production.
threshes.txt

from image-processing.

Ok, then let's stick with the command-line for now.

I also think that using the skimage slide widget sounds like a good solution to keep the lessons very similar, I did not know it exists.

@k-dominik Judging from Juan's comment scikit-image/scikit-image#4081 (comment) it will take a while before they depreacte it in favor of napari and if they do, only with a detailed guide on how to replace it.

from image-processing.

Thanks for the discussion folks. Glad we found a path forward!

from image-processing.

As for the trackbar issue, maybe we can change the way we go about that part of the lesson. The goal is to give users a way to determine a good threshold value (or other parameter), so how about a script that simply goes through a range of values and saves (or shows, perhaps) the resulting images?

This concept of parameter sweeping is a very important one, and of course this can work.

When working with image data I'm not sure wether one can determine a single threshold for a batch of images - so the interactive case makes more sense. First writing out a set of files with different thresholds (with fixed intervals, maybe writing out a new set with a more narrow range afterwards...) to determine the threshold would mean that at least two scripts would have to be run, vs. just one. It's not very user-friendly as compared to a "slider".

from image-processing.

I agree the trackbar is generally more convenient, especially when working on a semi-automated or manual workflow. In an automated image processing situation, parameter values such as thresholds would generally be determined once for a set of images, so writing out images within a range of values for a parameter is sufficient in that case. We are more often working in an automated context, so that's the perspective we generally come from in writing analysis code.

If the parameter sweeping script were written with parameter bounds as part of the input it seems that only one script would be required. A person would just run it multiple times with different inputs?

Even so, it sounds like the widget approach to implement a trackbar would still work. Even if the code is a bit obtuse, it can be 'glossed over' (and well commented in the code) for the workshop so that participants focus only on the parts of the code that are relevant in the moment. They would then be able to dig into it more outside of the workshop itself.

from image-processing.

Even so, it sounds like the widget approach to implement a trackbar would still work. Even if the code is a bit obtuse, it can be 'glossed over' (and well commented in the code) for the workshop so that participants focus only on the parts of the code that are relevant in the moment. They would then be able to dig into it more outside of the workshop itself.

I think that the code will be relatively straight forward with skimage.viewer. When I raised initial concerns about this, I was not aware about this functionality yet.

from image-processing.

Summarising here a some thoughts about this that I gave to Dominik in person:

• The important thing is to minimise the extraneous cognitive load (stuff they need to remember that isn't an essential part of what you want them to learn) for the learners. If the difference between uint8 and float64 is generally of importance/relevance when working with images (and it sounds like it is) then it's worth spending the time to include a discussion of this in the lesson material.
• However, to keep that extra cognitive load to a minimum, I recommend avoiding a lot of unnecessary switching back-and-forth between the two types. So I think it's a good idea to start with uint8s and make the switch to floats at the first opportunity without ever switching back, if such a path through the material is possible.

from image-processing.

I discussed this with @k-dominik and we decided to use float where it's appropriate.
This means we will need to change a bit in the thresholding episode (the threshold values) and we will add a few paragraphs in the first episode to explain the concept of images represented by floating point numbers and why this is a good idea (numerical accuracy).

from image-processing.

I can't speak for @mmeysenburg, @tessalea, or @ErinBecker but, for my money, it's better to make substantial changes during conversion and keep the extra cognitive load to a minimum than it is to try to change as little as possible and end up teaching a needlessly complicated pipeline. Of course, it also means more work for you so I would understand if you saw things differently...

from image-processing.

So our reasoning was the following:

We would want to teach the material in a way that is as close to "image analysis tasks with skimage in practice" as possible. And when doing this, it would be very impractical (and also less accurate) to always convert back to uint8, because most numerical skimage functions convert to float.

For example, coverting to grayscale, blurring or any other filter operation converts to float and
a typical workflow chains several of these operations. It would be very counter-intuitive to convert back to uint8 after each intermediate processing step. One could only convert in the end, but it's often necessary to apply thresholds or other operations that depend on value ranges on intermediate results.

from image-processing.

from image-processing.

Hi folks - I don't have anything to contribute to the specific benefits vs. downsides of floats vs uint8, but do agree with @tobyhodges's point about limiting switching back and forth as much as possible.

from image-processing.

I suggest closing this issue - there are plenty of new, finer grained issues out there that cover specific aspects of the skimage based lesssons now (also the big PR was merged...)

Good point, I have closed this for now.

from image-processing.