Convert sudoku.png image to pure RGB (without alpha channel) about image-processing HOT 9 CLOSED

It's all good, @uschille! I find it's a good thing that we have moved away from using argument as_gray=True with skimage.io.imread(), because it would change the dtype of this image implicitly (from uint8 to float64); without as_gray=True, skimage.io.imread(), would read it as uint8; imageio.v3.imread() reads it as uint8 regardless of RGB or grayscale.

from image-processing.

I'll find the issue some other time

cf. scikit-image/scikit-image#1234

No worries, thanks for the clarification @mkcor. I guess I was misinterpreting
https://pillow.readthedocs.io/en/stable/handbook/concepts.html#concept-modes.

I see!

from image-processing.

Thanks @mkcor. Just to make sure I understand correctly, you would favor uint8 as the default dtype for both RGB and grayscale images? I believe there are other episodes that use the range 0-1 for grayscale values, so those would need to be updated as well.

I also realized that there is potential confusion when using skimage.color.rgb2gray() which will implicitly convert the dtype to float64, so I'll check that skimage.util.img_as_ubyte() (as explained in Ep. 3) is used consistently throughout the lesson.

P.S.: I've thought about mode='F' but the pillow backend seems to only support float32 (not float64), which imho does not really help to avoid confusion.

from image-processing.

I think there is actually a more general question on how to handle grayscale images (uint8 vs. float64 and their ranges).

In episode 03-skimage-images, for example, we mention skimage.util.img_as_ubyte(). On the other hand, elsewhere in the same episode we say

Note that it is often better to use image values represented by floating point values, because using floating point numbers is numerically more stable.

Then in episode 05-creating-histograms, we use image = skimage.util.img_as_float(image).

To avoid confusion and reduce cognitive load, I would be in favor of streamlining and handling grayscale images consistently throughout the lesson - will open a separate issue for feedback and discussion.

from image-processing.

Pending discussion in #256.

from image-processing.

Hi @uschille,

Thanks @mkcor. Just to make sure I understand correctly, you would favor uint8 as the default dtype for both RGB and grayscale images?

No: It depends on the actual image at hand. My approach is very much practical and 'real-world' (images come as they are, some formats are more common in certain fields, etc.). So I think we should read images as they present themselves. And we should convert them only if we need to, e.g., if we want to apply specific transformations to them.

I believe there are other episodes that use the range 0-1 for grayscale values, so those would need to be updated as well.

That's not how I see it. If other episodes use other images, which have other dtypes, so be it. As you mentioned elsewhere, it illustrates the real world, where images come in different formats. From an educational perspective, what we want to convey is that it's important to be aware of the dtype of our images. Do we want to enhance the lesson with a line checking for the dtype each time an image is being loaded?

I also realized that there is potential confusion when using skimage.color.rgb2gray() which will implicitly convert the dtype to float64, so I'll check that skimage.util.img_as_ubyte() (as explained in Ep. 3) is used consistently throughout the lesson.

Ok.

P.S.: I've thought about mode='F' but the pillow backend seems to only support float32 (not float64), which imho does not really help to avoid confusion.

Interesting. For the purpose of this lesson, I would rather not distinguish between float32 and float64. Note that most functions in scikit-image are transparent to the various float dtypes.

from image-processing.

No: It depends on the actual image at hand. My approach is very much practical and 'real-world' (images come as they are, some formats are more common in certain fields, etc.). So I think we should read images as they present themselves. And we should convert them only if we need to, e.g., if we want to apply specific transformations to them.

I'm slightly confused. I thought the dtype is determined by the argument mode='...', so it can be chosen upon loading the image and may involve a conversion (in the case of the sudoku.png from 3x8-bit pixels to 1x8-bit pixels). I think that's useful in this case. In general I agree with you that we should only convert if needed.

From an educational perspective, what we want to convey is that it's important to be aware of the dtype of our images. Do we want to enhance the lesson with a line checking for the dtype each time an image is being loaded?

Yes, this is what I was trying to get to, how do we convey when to pass mode='...' and what mode to chose (and what to expect when no mode is chosen). I'm a bit wary of introducing too many technical details in the introductory lesson, but a short explanation/callout on dtype is a good idea 👍 We could add a short explanation at the point where a grayscale image is first loaded as float64.

from image-processing.

Sorry @uschille, I should be more precise in my wording: I should use 'conversion' only to mean colorspace conversion (which "RGB to grayscale" would fall under) vs. rescaling when changing the range of values (e.g., 0-255 to 0-1). This is something we have discussed at scikit-image (I'll find the issue some other time).

I thought the dtype is determined by the argument mode='...'

Not really, since adding this argument doesn't change the dtype. It was skimage.io's grayscale=True which did.

from image-processing.

No worries, thanks for the clarification @mkcor. I guess I was misinterpreting https://pillow.readthedocs.io/en/stable/handbook/concepts.html#concept-modes.

from image-processing.