imhist image pixel intensity uint8

Background/purpose: I am interested in using the Otsu method to threshold grayscale images. I am attempting to replicate the outsuthresh example found on Mathworks ( https://www.mathworks.com/help/images/ref/otsuthresh.html )

I downloaded the standard 8-bit "coins.png" image, and I loaded this image into my Workspace using imread.

Problem: After loading the coins.png image (uint 8) and a different image (uint16), the imhist function of the 8-bit image outputs image counts are in a single bin. I can't figure out how to interchangeable use imhist with 8-bit and 16-bit images.

I discovered that I can get the 'uint88" or "uint16" descriptor for the respective variables only if I imread directly from my Current Folder. Surely there is a way to use external paths to load images and define the pixel resolution.

[DGM]

If you're trying to download the file from somewhere else via imread() or something, then you're probably not getting the file you think you're getting. You might not even be working with an image at all. In order to know, we'd have to see an example of the code you're using to read the files.

That said, the coins.png image is included in the IPT imdata directory, so it's already on the path:

A = imread('coins.png');
class(A)

ans = 'uint8'

imhist(A)

imshow(A)

[J Toole]

@DGM -

First, I confirmed that I am using an identical 'coins.png' file. Thanks for letting me know the coins.png file is already in the IPT imdata directory.

Second, I believe my issue is that I am loading the image files as "double". See below:

ImagePath = 'C:\Users\Whoever';

FirstImage = 'Image1.tif';

LastImage = 'Image2.tif';

FirstImageFilePath = strcat(ImagePath,FirstImage);

LastImageFilePath = strcat(ImagePath,LastImage);

im = double(imread(FirstImageFilePath);

im2 = double(imread(LastImageFilePath);

Is there any reason for using "double(imread(file.tif))" instead of "imread(file.tif)"? I ask because later in my script, I later use "imhist", "reshape", and "imbinarize". I inherited this script, so I don't know why it was orginally coded this way.

I attached the image files in case there is something else bizarre occuring with these. I saved the two images as .png because .tif is not permitted file type in this forum.

[DGM]

For the purpose of reading the file, casting to double is not necessary; however, you need to be aware that you're then working with integer-class (uint8) data. Most all of the image processing tools know how to handle that just fine, but there are certain restrictions on what you can do with integer-class arrays without extra effort or precaution.

You would have to deal with the hazards of truncation and rounding when directly performing mathematical operations on them, and you're restricted on performing certain arithmetic between integer-class and float-class arrays. Whether any of that would be an issue in your case, I don't know. For imhist(), imbinarize(), it wouldn't be.

If you find that you do need to convert images to floating-point for some tasks, be aware that most tools that are scale-dependent will expect floating-point images to be unit-scale (0-1). When you use double() on a uint8 image, the values are not rescaled; while that may be a convenience in some cases, something like imshow() or imwrite() won't know what to do with it. When you use im2double(), the array is cast and rescaled. You can choose to design your workflow either way, but I recommend sticking with the canonical scaling (i.e. using im2double() instead of double()) unless you're familiar with how your tools will treat an image that's improperly-scaled for its class.

[J Toole]

Thanks so much.

Answer 1

[Image Analyst]

Don't cast it to double. There is probably no need to, unless you are going to use conv2. If imhist encounters a double variable it expects that the image will be in the range 0-1. Since most of the image is 1 or greater, all the counts will be lumped into the bin at value 1. If you just use double(), it won't be in that range, so you can/should use histcounts or histogram instead. You could use im2double, but again, I see no need to. I never use that.